Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 02 Jan 2018 09:56:09 -0800
From:      John Baldwin <jhb@freebsd.org>
To:        Julian Elischer <julian@freebsd.org>
Cc:        Colin Percival <cperciva@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r327447 - head/sys/sys
Message-ID:  <8492136.94UhKCrmBg@ralph.baldwin.cx>
In-Reply-To: <c6194248-8229-b46e-f9c6-0e96bcfeab5a@freebsd.org>
References:  <201712312100.vBVL0L0a038783@repo.freebsd.org> <c6194248-8229-b46e-f9c6-0e96bcfeab5a@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, January 02, 2018 11:56:31 AM Julian Elischer wrote:
> On 1/1/18 5:00 am, Colin Percival wrote:
> > Author: cperciva
> > Date: Sun Dec 31 21:00:21 2017
> > New Revision: 327447
> > URL: https://svnweb.freebsd.org/changeset/base/327447
> >
> > Log:
> >    Wrap includes in sys/tslog.h with #ifdef TSLOG.
> >    
> >    This is necessary because some non-kernel code #defines _KERNEL and then
> >    includes kernel headers; as a result, it was getting conflicting versions
> >    of curthread and curproc.  Non-kernel code should probably refrain from
> >    defining _KERNEL, but for now hiding these indirect inclusions fixes the
> >    build.
> 
> this is a recurring issue. Program that want to look into the 
> internals of files such as mount.h
> and define _KERNEL to allow themselves to do so.  It eventualy leads 
> to all sorts of confusion and pollution.
> Maybe we should make a policy on how to do this. At $JOB I had to hack 
> it to define a
> #ifdef _NOTREALLYKERNEL to split out parts we really wanted, but it 
> would be better to have specific ones for
> various specific 'rule breakers'..
> e.g.
> #if defined( _KERNEL ) || defined (WANT_TO_LOOK_AT_something)
> 
> kdump seems ot do the right thing with:
> 
> kdump/kdump.c:#define _WANT_KERNEL_ERRNO
> errno.h:#if defined(_KERNEL) || defined(_WANT_KERNEL_ERRNO)

The past few years we have been using _WANT_FOO when new things need to be
exposed and that is our current pattern.  However, that doesn't fix existing
code for old things.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8492136.94UhKCrmBg>