Re: Simple header cleanups

[Adrian Bunk <bunk@stusta.de>]

On Thu, Apr 27, 2006 at 03:00:16PM -0700, Linus Torvalds wrote:
> 
> 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).

Currently, it's sometimes non-trivial to figure out what is part of the 
ABI and what is not.

E.g. if you want to change a struct, how do you know whether it's part 
of the userspace ABI?

> > 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?

Agreed.

But let's discuss the naming after this discussion.

> 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.

Sure.

> 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.

I do still not get your point.

The ABI headers will be used by C libraries.

And by some programs doing low-level Linux specific things - but these 
are exceptions.

Normal userspace programs will simply not care about the contents of the 
kernel ABI headers - the libc will present them pretty headers adhering 
to all past, current and future standards.

This works today and it will continue to work.

> 			Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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