Messages in this thread | | | Date | Fri, 28 Apr 2006 01:12:00 +0200 | From | Adrian Bunk <> | Subject | Re: Simple header cleanups |
| |
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/
| |