Patches to get Arla running on FreeBSD 8-CURRENT

[Alec Kloss]

First off, I've got a few hours to work on this tomorrow night, so
if we could decide on an approach (and Robert can help me with the
heavy lifting) before then, that'd be super.  

On 2008-02-25 21:19, Robert Watson wrote:
> On Sun, 24 Feb 2008, Tomas Olsson wrote:
> 
> >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.

I can shed a little light.  It's definitely broken now as fs
nnpfsdeb almost-all has no effect.  I added the check for
PRIV_NNPFS_DEBUG in nnpfs_common-bsd.c:

+#elif defined(HAVE_KERNEL_PRIV_CHECK) && defined(PRIV_NNPFS_DEBUG)

because on my -current box PRIV_NNPFS_DEBUG isn't defined.  I
thought it might be an OpenBSD-ism.  Regardless, I would think it
*should* fall back to checking with suser() but apparently it
doesn't.  I can investigate a bit more, but removing nnpfs_deb.h
must have broader impact than we though.  Robert, any thoughts
about what PRIV_NNPFS_DEBUG should be?

> 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.

I think this is correct too.  Things like machine/endian.h aren't
in the kernel tree.  I should be able to autoconf this for just
FreeBSD if that's how we want to approach this.  If you want
to have configure generate these headers like vnode_if.h, I'll
probably need a few hints, but I'll do what I can.

> 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.

And I added the cf check... I found HAVE_THREE_ARGUMENT_VOP_UNLOCK
was undefined in ./nnpfs/bsd/nnpfs_vnodeops-common.c and figured
it's smarter to just add the check than assume something about
VOP_UNLOCK from the VOP_LOCK macros.  

-- 
Alec Kloss  alec at SetFilePointer.com   IM: angryspamhater at yahoo.com
PGP key at http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA241980E
"No Bunny!" -- Simon, from Frisky Dingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.stacken.kth.se/pipermail/arla-drinkers/attachments/20080225/9b41770b/attachment.bin