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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
