Date: Mon, 25 Feb 2008 22:22:25 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Alec Kloss <alec-keyword-arla.4d43de@SetFilePointer.com> 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: <20080225221920.A46736@fledge.watson.org> In-Reply-To: <20080225221533.GH28956@hamlet.SetFilePointer.com> 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> <20080225221533.GH28956@hamlet.SetFilePointer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 25 Feb 2008, Alec Kloss wrote: > 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? PRIV_NNPFS_DEBUG is a definition that will appear in FreeBSD 7.1, but 7.0 was already in final freeze when I added it to 8.x + 7.x. The reason I didn't have a specific check for PRIV_NNPFS_DEBUG is that I adapted nnpfs for 8.x, but not 7.0. If priv(9) is present but not PRIV_NNPFS_DEBUG, we should use PRIV_ROOT for now. >> 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. Indeed, it was machine/endian.h that did it. 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?20080225221920.A46736>