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