Date: Fri, 19 Jan 2018 10:02:05 -0800 From: John Baldwin <jhb@freebsd.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: Julian Elischer <julian@freebsd.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Colin Percival <cperciva@freebsd.org> Subject: Re: svn commit: r327447 - head/sys/sys Message-ID: <8141815.ryMSfkxlDd@ralph.baldwin.cx> In-Reply-To: <20180117231437.GQ8113@FreeBSD.org> References: <201712312100.vBVL0L0a038783@repo.freebsd.org> <8492136.94UhKCrmBg@ralph.baldwin.cx> <20180117231437.GQ8113@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, January 17, 2018 03:14:37 PM Gleb Smirnoff wrote: > On Tue, Jan 02, 2018 at 09:56:09AM -0800, John Baldwin wrote: > J> > this is a recurring issue. Program that want to look into the > J> > internals of files such as mount.h > J> > and define _KERNEL to allow themselves to do so. It eventualy leads > J> > to all sorts of confusion and pollution. > J> > Maybe we should make a policy on how to do this. At $JOB I had to hack > J> > it to define a > J> > #ifdef _NOTREALLYKERNEL to split out parts we really wanted, but it > J> > would be better to have specific ones for > J> > various specific 'rule breakers'.. > J> > e.g. > J> > #if defined( _KERNEL ) || defined (WANT_TO_LOOK_AT_something) > J> > > J> > kdump seems ot do the right thing with: > J> > > J> > kdump/kdump.c:#define _WANT_KERNEL_ERRNO > J> > errno.h:#if defined(_KERNEL) || defined(_WANT_KERNEL_ERRNO) > J> > J> The past few years we have been using _WANT_FOO when new things need to be > J> exposed and that is our current pattern. However, that doesn't fix existing > J> code for old things. > > As one who added a lot of _WANT_FOOs, I must admit that I don't consider > that a final and clean solution. But this seems to be a lesser evil when > dealing with old code that has multiple dependencies. > > New code needs to be written in a fashion that clearly separates kernel > structures from user visible structures, so that no tricks with preprocessor > are needed. The problem is that some kernel things aren't generically useful for userland and really should be opt-in, e.g. the negative errno values _WANT_KERNEL_ERRNO protects that only the kernel uses and very few things in userland should see. We will always have some system tools that are bound to the kernel that will need to understand certain kernel internals that the vast majority of userland programs will not / should not need. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8141815.ryMSfkxlDd>