"Robert V. Baron" <rvb_at_cs.cmu.edu> writes:

> This was a slip up that was only in FreeBSD 2.2.x kernels.  vop_select
> should be defined and made to function like ufs_select ... it returns 1.

That sounds good to me.  I had a crazy thought about being able to
open a file and have that operation succeed right away even if the
file wasn't in-cache and then select returning true when the file was
available, but it's probably best not to go there right now...

> Again, coda does not support either mknod or mkfifo.  We could discuss

Agreed - I had no desire to actually do mknod - I just found it by
kernel source inspection to be a simple test case to crash my kernel
and demonstrate the bug.

> Right now we are just returning an error.  I am returning EIO -- which

That's fine - I don't really care what the error is.  But EIO seems
wrong - there is no actual I/O error, but instead one is doing an
operation not supported by a filesystem.  I feel that EIO should be
somehow possibly transient, that if one gets EIO the operation should
at least have a chance to succeed later.

> We had not planned to go on supporting 2.2.x when we switched to
> -current on FreeBSD (The same applies to NetBSD.).  Up till very

I can appreciate your resources constraints, but I feel this is
unfortunate.  My group is running FreeBSD 2.2.x and NetBSD 1.3.2,
because tracking -current is too painful.  We are adding our own
stuff, and trying to run coda, and keeping up with -current on top of
that would be too hard, IMHO.  I expect to shift to 3.1 or whatever in
the spring or summer.  (ie I only want cutting edge in areas I choose
it.)
Most people I know that use *BSD for work run some version of -stable,
althought I realize Real Hackers(tm) run -current.  So I believe that
having coda work on -stable is important to building a user base.

> 		pub/coda/freebsd/2.2.x/i386

Thanks for the pointer.  I've actually built everything I'm running
from source, so perhaps I spoke too soon above.  Since it seems like
the kernel stuff is stable, modulo the bug I just found, I expect I'll
be able to compile the newer stuff without problems.

BTW I'm in the process of setting up a 'real' server, one with raw
partitions, 3 Gb of /vicepa and 256Mb of RAM (FreeBSD/i386 2.2.x).  I
think someone here may also port things to NetBSD/sparc 1.3.2, since
we have a bunch of those.  My 'test' server has been working stably
for a few months, with a half-dozen clients.

        Greg Troxel <gdt_at_ir.bbn.com>