Re: Simple header cleanups

[Linus Torvalds]

On Thu, 27 Apr 2006, Adrian Bunk wrote:
> 
> A definition of the kernel <-> userspace ABI is required.

Well, we can get certain hints by just looking at every single type that 
is used as a __user pointer. That should give us a lot of the type 
information.

The other big piece ends up being argument values passed in to system 
calls, most notably ioctl numbers, but there are certainly others too.

And then there are the system call numbers themselves, and their calling 
conventions (fairly small part).

> Create an include/kabi/linux/ with the following properties:

I do hate your naming.

Why is that "linux" there? We're not going to have FreeBSD kabi files. And 
what about the (pretty common) architecture-specific ones?

The dependency chain is also quite often nontrivial. The ABI's all end up 
depending on the basic types, and often on each other (eg the ioctl 
numbers depend on the sizes of all the structures, which in turn depend on 
the architecture-specific structure layout and low-level types).

So it's _not_ usually possible to just do one file that does one thing, 
because they do actually have linkages.

And the linkages can be nasty, because they can easily be linkages that 
POSIX - and other standards - forbid them from being visible (you cannot 
expose certain typenames if they weren't _explicitly_ included, regardless 
of whether you need the type defines).

This is one reason why we shouldn't even _plan_ on having header files 
that can just be _directly_ used by the C libraries etc, even if it's just 
a "small" kernel ABI header.

Selling it as that kind of idea will inevitably mean that we then get 
blamed for not knowing magic rule #579 for SuS v2.1.6 subsection 8(a).

And if we say "you can use these headers unmodified", that _is_ what we're 
going to get blamed for. I'm so _not_ interested in having to care or 
worry.

So I seriously think we should aim for making it _easier_ for system 
libraries to get the information, but we should at the same time make it 
clear that we make it easier for them to get the basic info, BUT WE DO NOT 
CARE ABOUT THE RANDOM USER STANDARD OF THE DAY.

Have you looked in /usr/include lately? Have you _looked_ at the "expose 
BSD names" vs "GNU extended source" vs "strict POSIX" vs 
"_XOPEN_SOURCE==600" bs "_USE_MISC" vs a million random and strange 
things?

The day I see somebody adding crap like that to the kernel headers is the 
day I pull the plug on any "KABI" interfaces. 

And don't tell me this has got nothing to do with the kernel constants. Go 
look in something like /usr/include/bits/fcntl.h, and cry. See how it's 
using _exactly_ the kernel constants, but it has added all the random 
standard-of-the-day #ifdef (whether real standards, or the "GNU standards" 
or just "legacy BSD-like" etc).

And THAT is why I don't think the simplistic "kabi" directory approach 
that people have brought up many times over many years is actually 
realistic. People don't realize that glibcs makes "struct flock" actually 
look different in user space depending on whether "__USE_FILE_OFFSET64" is 
defined or not.

You just haven't seen just how NASTY those user-space headers are. They 
can't use _any_ kernel headers directly, because even when they want a 
_raw_ kernel data structure, they actually end up doing things differently 
in the _middle_ of that data structure. 

Really.

So we should try to help those system libc people perhaps _find_ the 
values and structures they need, but no, I will _never_ allow the kernel 
headers to be used directly. And it doesn't _matter_ if they've been moved 
to a "kabi" subdirectory. That's not the issue. The issue is that user 
space does insane things that aren't acceptable in kernel space.

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/