Why you should use linux-libc-headers FAQ section

Denis Trofimenko denis at quart-soft.com
Fri Jul 2 04:01:21 PDT 2004


Hi, Jeroen


I'm sorry for being so long. Here is linux-libc-headers FAQ in txt format. It 
contains an origin information on what it based, questions list in the top of 
it and actual FAQ (Q&A). I hope it will be useful.



В сообщении от Четверг 24 Июнь 2004 00:03 Jeroen Coumans написал(a):
> Denis Trofimenko said the following on 23-06-2004 20:54:
> > So I will send it to you when it will look like :
> > [original information, on which the faq is based]
> > Q: question
> > A: answer
> >
> > Will it be OK for you to use?
>
> That will be perfect, thanks!
>
> --
> Groeten/Greetings,
> Jeroen Coumans
> {faq,website}@linuxfromscratch.org
> www.jeroencoumans.nl

-- 
Best regards,
	Denis.
-------------- next part --------------
As I wrote before, first I want to put a list of questions of this FAQ, then original information will go, and then there will be actual FAQ.

Hope you will find it enough useful to put it in the FAQ section to end all that issues when people are trying to build the system using raw headers.

Q:Why I shouldn't use raw kernel headers to compile userspace applications?
Q:Why you are using raw kernel headers to compile glibc?
Q:If I shouldn't use raw kernel headers to compile userspace applications, then what I should use?
Q:But the linux-libc-headers is not supported by kernel developers, I better should contribute to glibc developers?
Q:Is there any alternative for linux-libc-headers and should I search for one?
Q:What doing kernel developers to resolve the situation?

--------------------
Here the links to the source of thread on kernel-traffic:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0406.2/0526.html
And some useful links from discussion:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0406.2/0757.html
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0406.2/1179.html
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0406.2/1231.html
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0406.2/1469.html

Here a cutoff from the thread, which contains all that we need:

-----------------------------
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0406.2/0757.html

"David Schwartz" <davids at xxxxxxxxxxxxx> writes:

> It creates a stable system. Things become much less stable if you mess
> around with all of userspace just because the kernel changes. There is no
> reason user space should be in sync with the running kernel. User space
> should be stable.

Kernel headers should and in fact are stable WRT common userspace
interface. If they aren't, you're forced to recompile the userspace
anyway.

BTW: it's ok to compile things like glibc against new kernel headers
(say, 2.6.x) and use the resulting library with older kernels (as old
as 2.2 I think). In fact it's the preferred way to compile glibc.
You can disable support for older kernels with glibc/configure
--enable-kernel=VERSION --enable-oldest-abi=ABI.

> The kernel-user interface is supposed to stay stable, so you shouldn't need
> to make significant user space changes when you upgrade the kernel. Only
> specific applications that need to get specific new features that require
> changes to the kernel-user interface need to change.

Sure. Examples: ioctls for configuring the system.

> It has been a very long
> time since compiling user space programs against the header files for the
> kernel you happened to be running was considered good practice.

I think at this point we have to create include/abi (or api) as a part
of the kernel. The mess with distributions-provided "glibc kernel
headers" must at last be cleaned.

Should no one have time for doing that I'm going to start.

-- 
Krzysztof Halasa, B*FH

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0406.2/1179.html

On Thursday 17 June 2004 18:28, Nick Bartos wrote:
> I have a little distro that I am trying to upgrade to 2.6.x.
>
> The problem is that when I use the headers for 2.6.x, glibc 2.2.5 won't
> compile. Eventually I want to upgrade glibc/gcc, but not at the moment.
> If I use the headers from 2.4.26 for the system, but just compile the
> 2.6.7 kernel, things do compile fine for everything.

The linux-kernel maintainers apparently decided that C libraries using kernel 
headers to actually interface with the kernel was a bad idea. Apparently, 
interfacing with the kernel from a C library is not a proper use for kernel 
headers, or something. (I tried to follow the logic in this discussion, but 
never actually found any, despite repeated attempts. It always seemed to 
boil down to "can't be bothered", "userspace shouldn't use kernel headers and 
this includes the C library", etc...)

On a pragmatic level, you want the cleaned up 2.6 kernel headers maintained by 
Mariusz Mazur <mmazur at xxxxxxxxx> which you can download from:

http://ep09.pld-linux.org/~mmazur/linux-libc-headers/

> I see that a lot of distros use a separate package for the kernel headers,
> which do not necessarily coincide with the running kernel.

Yup. It sucks, but there's no alternative for 2.6.

Mazur does a good job, though.

> I am wondering what (if any) are the side effects of doing this are,
> especially when the kernel versions are so different.

You're generally safe using older header versions. (Heck, you can use 2.4 
headers to build your C library if you like. The resulting C library just 
won't be able to use various new features like more than 256 minor numbers 
for devices, or possibly the ability to burn with ATA CD-ROM drives without 
SCSI emulation...)

> I was thinking that
> there may be issues with some progs if the prototypes for certain kernel
> functions weren't the same. However people are doing it and it does seem
> to work, but I am wondering how it fends for stability.

If using old headers didn't work on new kernels then using old binaries 
wouldn't work on new kernels. And that would be noticed big time. (We can 
still run binaries that ran on Linux 0.01. A couple minor things have been 
ripped out over the years, but not much. The big backwards compatability 
issue is generally making sure you have the relevant old versions of the C 
library installed if you really want to run WordPerfect 6 or Netscape or 
such....)

Rob

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0406.2/1231.html

On Sat, Jun 19, 2004 at 05:46:50AM -0500, Rob Landley wrote:
> The linux-kernel maintainers apparently decided that C libraries using kernel 
> headers to actually interface with the kernel was a bad idea. Apparently, 
> interfacing with the kernel from a C library is not a proper use for kernel 
> headers, or something. (I tried to follow the logic in this discussion, but 
> never actually found any, despite repeated attempts. It always seemed to 
> boil down to "can't be bothered", "userspace shouldn't use kernel headers and 
> this includes the C library", etc...)

No, the problem is that the only thing that needs to be shared are the
_ABI_ headers, which are unfortunately mixed in with kernel-internal
headers and definitions. This leads to use of kernel-internal
definitions in userspace, which leads to breakage. This also leads to
restrictions on changing -kernel-internal- headers, because some
userspace wanker is complaining.

Kernel-internal headers and definitions should absolutely never be used
in userspace.

H. Peter Anvin has suggested an include/abi which could be shared, and
this seem quite reasonable to me. However, the monumental task of
separating kernel-internal definitions from ABI definitions still
remains.

Jeff, really glad the linux-libc-headers guys started his effort

-

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0406.2/1469.html

On Sun, 20 Jun 2004 19:37:20 -0500 Rob Landley wrote:

| On Sunday 20 June 2004 11:24, Jeff Garzik wrote:
| 
| > Kernel-internal headers and definitions should absolutely never be used
| > in userspace.
| 
| Hence the old #ifdef KERNEL stuff, or whatever the guard was...
| 
| My only confusion was that when the #ifdefs stopped being maintained (written 
| off as inherently unworkable because people just #defined KERNEL when they 
| shouldn't), no actual replacement was pursued. Instead the attitude seemed 
| to be "this is glibc's problem", we're too busy trying to get 2.6 out to 
| actually worry about anybody using it. And calling it glibc's problem 
| doesn't work for me, because want to use uclibc...
| 
| > H. Peter Anvin has suggested an include/abi which could be shared, and
| > this seem quite reasonable to me. However, the monumental task of
| > separating kernel-internal definitions from ABI definitions still
| > remains.
| >
| > Jeff, really glad the linux-libc-headers guys started his effort
| 
| Mazur seems to be doing a really nice job of it so far. I'm building a small 
| distro based on it and sending him bug reports when I can't get something to 
| compile. I'm happy to use his work, but I'd rather it got integrated into 
| the kernel.
| 
| Now that it's mostly stabilized, it seems that the remaining work is mostly 
| auditing, integrating it in under the include/abi directory, and cleaning up 
| the normal kernel headers to include the abi stuff rather than defining their 
| own copies in the kernel internal headers.
| 
| If an abi directory was created, I'd be happy to submit a file or two at a 
| time into it (with the corresponding patches to remove the definitions from 
| the main include directory and #include abi/whatever instead...)
| 
| (Is there some effort _other_ than Mazur's work I should know about? Or 
| something wrong with Mazur's cleanups? Or somebody already doing this...?)

Yes, or sort of. There's a linuxabi mailing list:

http://zytor.com/mailman/listinfo/linuxabi

and talk about doing a big push on this in early 2.7.
There are several interested parties, but I don't know how interested
the top-level maintainer is in accepting such patches.


--
~Randy





------------------------------------



linux-libc-headers FAQ

Q:Why I shouldn't use raw kernel headers to compile userspace applications?
A:The problem is that the only thing that needs to be shared between userspace applications and kernel are the _ABI_ headers, which are unfortunately mixed in with kernel-internal
headers and definitions. This leads to use of kernel-internal definitions in userspace, which leads to breakage. This also leads to restrictions on changing -kernel-internal- headers, because some userspace wanker is complaining.

Kernel-internal headers and definitions should absolutely never be used
in userspace.

H. Peter Anvin has suggested an include/abi which could be shared and that will be real solution. However, the monumental task of separating kernel-internal definitions from ABI definitions still
remains.

Mariusz Mazur and his linux-libc-headers started his effort.
Maybe someone don't like this idea, but Mr. Mazur's work is only real working solution for now and maybe forever for 2.6 kernels, because cleaned up ABI can appear only in 2.7 kernels (see "What doing kernel developers to resolve the situation?" section)

Q:Why you are using raw kernel headers to compile glibc?
A:It's ok to compile things like glibc against new kernel headers (also called raw kernel headers)
(say, 2.6.x) and use the resulting library with older kernels (as old
as 2.2 I think). In fact it's the preferred way to compile glibc.
You can disable support for older kernels with glibc/configure
--enable-kernel=VERSION -enable-oldest-abi=ABI.
Actually the only thing which can be compiled with raw headers is glibc (and it should be compiled with raw headers).

Q:If I shouldn't use raw kernel headers to compile userspace applications(all applications except glibc), then what I should use?
A:On a pragmatic level, you want the cleaned up 2.6 kernel headers maintained by 
Mariusz Mazur <mmazur at xxxxxxxxx> which you can download from:
http://ep09.pld-linux.org/~mmazur/linux-libc-headers/
A lot of distros use a separate package for the kernel headers,
 which do not necessarily coincide with the running kernel. It sucks, but there's no alternative for 2.6.
Mazur does a good job, though.

Q:But the linux-libc-headers is not supported by kernel developers, I better should contribute to glibc developers?
A: As one of kernel developers said(http://www.uwsg.indiana.edu/hypermail/linux/kernel/0406.2/1469.html):
"Instead the attitude seemed to be "this is glibc's problem", we're too busy trying to get 2.6 out to 
 actually worry about anybody using it. And calling it glibc's problem 
 doesn't work for me, because want to use uclibc..."
To sort off - this is not a glibc problem, to contribute to glibc is good idea :) but it will never solve this problem. If you want to solve this problem, you should better contribute to linux-libc-headers project.
I also want to see linux-libc-headers integrated into kernel, but it works fine now, so the main benefit of integrating it to kernel will be less people asking questions why they should use linux-libc-headers :)

Q:Is there any alternative for linux-libc-headers and should I search for one?
A:You shouldn't even search for one. You better should wait for kernel 2.8,where cleaned up ABI will appear, but for kernel 2.6 use linux-libc-headers project.
However, there is one known to me alternative :
There's a linuxabi mailing list:
http://zytor.com/mailman/listinfo/linuxabi
But you should still use linux-libc-headers from Mr. Mazur, because it is real solution for kernels  2.6

Q:What doing kernel developers to resolve the situation?
A: They are waiting :) Waiting for cleaned up ABI, which will appear only in 2.7 kernels (after 2.7 kernel will appear, they will begin to work on cleaning up ABI). So cleaned up ABI is targeted for 2.7 kernels and by the sake of linux-libc-headers from Mr.Mazur we can build our system using 2.6 kernels. 


More information about the faq mailing list