> That function does not _appear_ to be in the mklinux sources--at least a
> grep didn't find it...  ;-)

I think the point was that there's an equivelant development effort for
Linux. The developer's here at Stanford, and I think we've actually
taken a few classes together.

This fact begs the question, "should we switch to hfs_fs from Macfs?"
I'm not sure. Paul and I are coming along with MacFS. It links, mounts,
and almost unmounts. The last problem, which I discovered right at bed
time last night, is that there's a locking problem in the unmount code
(basically we try to lock something when we already have the lock).

I've looked at hfs_fs, and it seems to be moving along well. Its
advantage would be that it has a larger development effort than
MacFS (at the moment). Its disadvantages are: 1) Paul G. and I'd have
to learn a whole new package, and 2) I don't know how different
the vfs interfaces are. Both packages have Copyright issues, as AFAIK
core doesn't want something GPL'd in the kernel (as the whole kernel
binaries might then become GPL'd or some such). MacFS's Copyright basically
prohibits use in military applications, but seems fine other than that.
hfs_fs is GPL'd. I haven't asked its keeper if he'd let us use it under
the NetBSD copyright (with bug fixes & improvements going both directions),
mainly as I only learned about it this morning. :-)

Just for reference, what (if any) is the procedure/standard/precedent
for adding other-than- BSD copyritten code to the kernel? Well, I know
to get it into the tree (whom to ask), but other than that...?

Take care,

Bill