On Sun, Feb 11, 2007 at 01:48:26AM +0100, Davor Ocelic wrote:
> 
> Please take a look at
> 
> 	http://coda.wikidev.net/Quick_Test_Coda
> 
> and update information for other kernels and operating systems
> in the same summarized way as I did for Linux and Debian GNU.

Nice, I have some comments, although I'm not sure if they are really
necessary,

  Building from source

    export CVSROOT=:pserver:anonymous_at_coda.cs.cmu.edu:/coda-src
+   cvs login
+   (empty password)
    cvs -z3 co -P lwp

Shouldn't there be a 'cvs login' before the checkout? Or has the use of
cvs login become unnecessary now that anonymous cvs repositories are
pretty much everywhere.

  Follow up operations

    sudo coda-setup-ports
    sudo venus-setup realm
    sudo codaconfedit venus.conf kerneldevice \
	`sudo find /dev -name cfs0 | head -n 1`

I don't think coda-setup-ports is really necessary anymore. The Coda
ports were registered with IANA in 1997 or 1998 and pretty much every
/etc/services file has those entries by default.

venus-setup may create a couple of directories that the Coda client
probably should just do when it is started for the first time, maybe it
already does. The realm here is unnecessary for first users. Venus (the
Coda client) actually doesn't even use that information, only
clog/cpasswd use it if the realm is not explicitly specified. If I type
'clog' without arguments it will prompt for a password for my local
login name @ default realm in the venus.conf file (which is the one set
by venus-setup). Also the client tries to avoid realms that don't look
like fqdn names, i.e. without any periods in the name. It would be
better to use realm.local or something similar.

Finally the cfs0 device is created by udev after the kernel module is
loaded. udev is kind of annoying that way, with the traditional static
/dev and devfs, the cfs0 device always existed and the coda kernel
module is autoloaded whenever it is opened. With udev everything is
turned around, it expects that hardware is found, which loads a module
which in turn triggers the creation of the device node. Of course with
Coda there is no hardware to be found, so this doesn't work. One
workaround I've used is to add "/sbin/modprobe coda ; /sbin/udevsettle"
to the init script before starting venus, but I think udevsettle may not
exist for all used versions of udev.

I'm not yet sure what the best solution for this is, maybe venus should
create /dev/cfs0 if it doesn't exist, open the device and rely on the
kernel autoloader, maybe modprobe + udevsettle is better in the long run.

Jan