Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[David Woodhouse <dwmw2@infradead.org>]

On Mon, 2004-11-29 at 09:41 -0800, Linus Torvalds wrote:
> In fact, in many ways I'd prefer to have source-level annotations like 
> "this is exported to user space" over trying to gather things in one 
> place.

I don't think you would; not once you really tried it. 

That's what the littering of ifdef __KERNEL__ attempts to do, and
there's not really any better way of doing it than that. Whatever form
of annotation you came up with, it wouldn't be much different to using
__KERNEL__ and performing the 'export' step using unifdef. Changing the
sense of it so that we annotate the stuff which _is_ visible rather than
the stuff which _isn't_ doesn't really make it fundamentally different
either.

If we want to make stuff cleaner in userspace that means spreading the
headers much more liberally with such ifdefs or whatever trick we use to
replace them. It gets ugly quite fast -- and we already know that the
fix for having too many ifdefs is to split stuff up more sensibly. 
By splitting the visible parts into separate files we actually help to
make people _think_ when they're exposing stuff to userspace, and it
would help to direct particularly close attention to reviewing
structures therein. For example, if the netfilter people tried to add
this to a header file which is explicitly for userspace consumption,
rather than hidden away in kernel private headers and just _happening_
to be part of the userspace ABI, they'd never get away with it:

struct ipt_rateinfo {
	u_int32_t avg;    /* Average secs between packets * scale */
        u_int32_t burst;  /* Period multiplier for upper limit. */
 
        /* Used internally by the kernel */
        unsigned long prev;
        u_int32_t credit;
        u_int32_t credit_cap, cost;
 
        /* Ugly, ugly fucker. */
        struct ipt_rateinfo *master;
};

Use of an 'unsigned long' which gratuitously changes the structure size
between 32-bit userspace and 64-bit kernel, without even any _reason_
for it being there. That kind of thing would be far more obvious if the
headers are split, and much less so if we continue as we are. 

That and the ugliness of the __KERNEL__ or whatever other annotation
scheme we come up with are the main reasons why I think it wants to be
separate header files for sharing with userspace, rather than continuing
with the mess we have.

Let's go through the kernel headers and identify what actually needs to
be exported; yes. But let's not 'annotate' it and post-process the mess
of header files to sanitise it; let's just take the parts which need to
be shared, put them into different header files and include them from
there.

-- 
dwmw2