Patches to get Arla running on FreeBSD 8-CURRENT

[Robert Watson]

On Sun, 24 Feb 2008, Tomas Olsson wrote:

> I wrote:
>> On Sat, 2008-02-23 at 10:12 -0600, Alec Kloss wrote:
>>> All of the heavy lifting is done in the big patch at
>>>
>>> 	http://setfilepointer.com/pub/arla/20080223-arla.diff
>> [...]
>>> Can anyone from Arla comment on the chances for incorporating these 
>>> patches into Arla itself?  It'd be nice to have these changes in Arla 
>>> itself prior to submitting the port to FreeBSD.
>>>
>> Chances are good. If it looks ok it goes in.
>>
> Looks mostly ok, but I do have some questions.
>
> 1) appl/fs/fs_local.h: would that break `fs nnpfsdeb all`?
>
> 2) cf/try-compile-kernel.m4: why do we need /usr/include? It sounds scary 
> given that we may want to compile using random kernel trees. Same goes for 
> nnpfs/freebsd/FreeBSD-Makefile. I don't know much about kernel build magic.
>
> 3) cf/bsd-vop-unlock.m4: do we need it? I don't care about older versions of 
> FreeBSD than 6.x; traditionally we try to support latest stable OS-release 
> plus -CURRENT but maybe that's a bit limiting. Perphaps nnpfs_vfs_unlock 
> solves part of the problem?

Just back from FOSDEM, and am 3-4 days behind on e-mail, so will need to 
investigate (1) and (2) in a day or two.

If I've done (1) correctly then, in practice, it shouldn't change things at 
all, except that on FreeBSD 7.x and higher, it will use the priv(9) interface 
to check for privilege rather than suser(9).  While there are plans for 
further privilege semantic changes, the interface change so far is actually a 
syntactic change -- the policy remains the same, but information about the 
check is managed differently, hence the change to the interface.  This is a 
precursor to more fine-grained privileges in the kernel.

With respect to (2), I need to look at the details, but I believe this has to 
do with the fact that nnpfs is relying on generated files that may not be 
present in a kernel source tree.  The more right fix may be to force 
generation of the files (if we can) in the nnpfs build, as we already do for 
vnode_if.h, but I'll have to look in more detail.

With respect to (3) -- that has to do with support for 8-CURRENT, not pre-6.x. 
It looks like the VFS folks are in the middle of dropping unnecessary thread 
arguments from various locking interfaces in VFS, including 
lock/unlock/assert/etc (these will now all be curthread implicitly).  I just 
saw a couple more such changes trickle in today, so I'll probably have some 
more patches, sadly.

Robert N M Watson
Computer Laboratory
University of Cambridge