Date: Mon, 25 Feb 2008 16:15:33 -0600 From: Alec Kloss <alec-keyword-arla.4d43de@SetFilePointer.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: afs@FreeBSD.org, arla-drinkers@stacken.kth.se, Tomas Olsson <tol@stacken.kth.se> Subject: Re: Patches to get Arla running on FreeBSD 8-CURRENT Message-ID: <20080225221533.GH28956@hamlet.SetFilePointer.com> In-Reply-To: <20080225211424.U46736@fledge.watson.org> References: <1203286882.16414.3.camel@heterodyne.kaj> <20080218012608.V96329@fledge.watson.org> <20080222125207.GD38141@hamlet.setfilepointer.com> <20080223092516.O23969@fledge.watson.org> <20080223102922.GF38141@hamlet.setfilepointer.com> <20080223110549.GG38141@hamlet.setfilepointer.com> <20080223161249.GH38141@hamlet.setfilepointer.com> <1203788012.4065.10.camel@hippo.t.nxs.se> <1203893910.4068.14.camel@hippo.t.nxs.se> <20080225211424.U46736@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--NzX0AQGjRQPusK/O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. =20 On 2008-02-25 21:19, Robert Watson wrote: > On Sun, 24 Feb 2008, Tomas Olsson wrote: >=20 > >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 scar= y=20 > >given that we may want to compile using random kernel trees. Same goes f= or=20 > >nnpfs/freebsd/FreeBSD-Makefile. I don't know much about kernel build mag= ic. > > > >3) cf/bsd-vop-unlock.m4: do we need it? I don't care about older version= s=20 > >of FreeBSD than 6.x; traditionally we try to support latest stable=20 > >OS-release plus -CURRENT but maybe that's a bit limiting. Perphaps=20 > >nnpfs_vfs_unlock solves part of the problem? >=20 > Just back from FOSDEM, and am 3-4 days behind on e-mail, so will need to= =20 > investigate (1) and (2) in a day or two. >=20 > If I've done (1) correctly then, in practice, it shouldn't change things = at=20 > all, except that on FreeBSD 7.x and higher, it will use the priv(9)=20 > interface to check for privilege rather than suser(9). While there are= =20 > plans for further privilege semantic changes, the interface change so far= =20 > is actually a syntactic change -- the policy remains the same, but=20 > information about the check is managed differently, hence the change to t= he=20 > interface. This is a precursor to more fine-grained privileges in the=20 > 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 ha= s=20 > to do with the fact that nnpfs is relying on generated files that may not= =20 > be present in a kernel source tree. The more right fix may be to force= =20 > generation of the files (if we can) in the nnpfs build, as we already do= =20 > 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=20 > pre-6.x. It looks like the VFS folks are in the middle of dropping=20 > unnecessary thread arguments from various locking interfaces in VFS,=20 > including lock/unlock/assert/etc (these will now all be curthread=20 > implicitly). I just saw a couple more such changes trickle in today, so= =20 > 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. =20 --=20 Alec Kloss alec@SetFilePointer.com IM: angryspamhater@yahoo.com PGP key at http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xA241980E "No Bunny!" -- Simon, from Frisky Dingo --NzX0AQGjRQPusK/O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFHwz4F2s33paJBmA4RAnEBAJ0UBK7+mSNNb2JhNqM0SQlSiYx0dwCePdWr muiPFvbVf5tqALxh/VqI9oY= =IW+D -----END PGP SIGNATURE----- --NzX0AQGjRQPusK/O--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080225221533.GH28956>