Date: Mon, 25 Feb 2008 21:19:24 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Tomas Olsson <tol@stacken.kth.se> Cc: Alec Kloss <alec-keyword-arla.4d43de@SetFilePointer.com>, afs@FreeBSD.org, arla-drinkers@stacken.kth.se Subject: Re: Patches to get Arla running on FreeBSD 8-CURRENT Message-ID: <20080225211424.U46736@fledge.watson.org> In-Reply-To: <1203893910.4068.14.camel@hippo.t.nxs.se> References: <20080216035658.W93919@fledge.watson.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080225211424.U46736>