What's the difference between arch-specific header files of uClib and those header files of linux kernel

Rob Landley rob at landley.net
Fri Mar 23 19:26:03 UTC 2007


On Thursday 22 March 2007 10:53 pm, Ahan Hsieh 謝武漢 wrote:
> Dear all,
> 
> Now, I want to port uClibc to a new architecture. 
> And I have already port uCliunx to this architecture.
> 
> When I port uClibc to this new architecture, I got a trouble.
> 
> Take fcntl.h as an example:
> In uClibc/libc/sysdeps/linux/ARCH/bits/fcntl.h of uClibc, 
> there is also a fcntl.h in linux-2.6.x/include/asm-ARCH/fcntl.h of linux 
> kernel.

Ok, my understanding of the situation:

Back before 2.6.19, Linux didn't have a "make headers_install" target.  The 
Linux kernel didn't export a clean set of headers that defined its' API with 
userspace (the ones Linux uses to build itself have all sorts of internal 
gunk mixed in, and couldn't be used directly without significant cleanup).

Lots of different efforts to create cleaned up kernel headers sprang up, the 
PLD headers from Marius Maszur, the glibc guys had one, David Howells of Red 
Hat maintained a set, the Linux From Scratch guys had a script to filter the 
kernel headers...  The problem is that the kernel's userspace API keeps 
expanding as the kernel gains new abilities (new syscalls and such), so if 
you were using old kernel headers your C library couldn't use things like 
larger than 8 bit major:minor numbers in devices, burning CDs using DMA...  
(For _really_ old headers even PIDs larger than 16 bits).  You wanted to use 
the most up-to-date kernel headers you could, but manual translation was a 
huge amount of work and the scripts to automate cleanup would break on a 
regular basis.

Then David Howells got fed up with the unnecessary work and taught the kernel 
to export its own headers, and the result is that now you can get kernel 
headers from the kernel.  This is a recent development, and the first few 
releases were buggy in different ways.  (Before 2.6.19.1 it didn't work at 
all, before 2.6.20 the networking headers were missing some symbols...)  
They're still poking and prodding to make sure everything works.

So while everybody and their mother were doing their own kernel headers, the 
uClibc guys decided "ok, we're going to have our own kernel headers 
describing all the features that uClibc knows how to use", so they copied 
them and started a cleanup but there was a boatload of work to finish it.  
(This is why you still need to specify where to find kernel headers when 
building uClibc.  The ones they copied and tried to clean up by hand never 
got finished.)

Now that the linux kernel's headers_install target is rapidly maturing, that 
stuff isn't needed in uClibc and can be ripped back out again.  Maintaining 
an out-of-tree copy of files that the Linux kernel can now produce usable 
versions of doesn't make sense any more.

Rob
-- 
Vista: Windows Millenium Second Edition



More information about the uClibc mailing list