sanitized kernel headers

sanitized kernel headers

[Alexander E. Patrakov]

Hello,

almost two years ago, a decision has been made that raw kernel headers 
are for the kernel only, and that userspace should be built against some 
"sanitized" kernels. Linux-Libc-Headers 
(http://ep09.pld-linux.org/~mmazur/linux-libc-headers/) were one of the 
implementations of such sanitized headers, and they worked well and were 
used e.g. in Linux From Scratch.

But now, the Linux-Libc-Headers project looks dead: no commits in the 
SVN for the last two months, and the only changes in SVN as compared to 
LLH 2.6.12.0 are addition of inotify.h, removal of some kernel-only 
headers and some minor fix for non-glibc systems.

What is the recommended (non-dead) alternative implementation of such 
"sanitized" headers? Where is the roadmap for this area?

-- 
Alexander E. Patrakov
Don't mail to patrakov@ums.usu.ru: the server is off until 2006-01-11
Use my GMail or linuxfromscratch address instead

Re: sanitized kernel headers

[Andrew Walrond]

On Saturday 07 January 2006 09:59, Alexander E. Patrakov wrote:
>
> What is the recommended (non-dead) alternative implementation of such
> "sanitized" headers? Where is the roadmap for this area?

I still don't buy the arguments of the kernel maintainers who shun 
responsibility for this. My undoubtedly naive position is that

1) The kernel does a load of really clever low level stuff, and presents a 
stable API that the rest of the world (userspace) can use

2) Every part of that API that userspace needs should be presented to 
userspace in a consistent and reliably useable way

3) Any part of the kernel to which userspace absolutely needs access _must_ be 
part of that consistently and reliably presented API.

This 'sanitized kernel headers' mess (the single biggest _PITA_ for all small 
independent  linux distro creators/maintainers) should either

1) be unnecessary
2) be included as part of the kernel sources and acknowledged as specifically 
for use by userspace

Currently affected userspace packages include stuff like glibc, directfb, 
netfilter, iproute2, alsa, iputils, pcmcia-cs, udev and wireless-tools.

Andrew Walrond
[thumbs nose, dons hardhat, dives into hastily prepared bunker]

Sanitized kernel headers

[Peter Kjellerstedt]

In a recent commit 
(http://cgit.openembedded.org/openembedded-core/commit/?id=c27ac156bcaf3193d52f456480947b0cfaef3c72), 
Richard added a big warning about not forking the 
linux-libc-headers recipe to get at specific kernel 
headers for user space. As a consequence I thought I 
should remove our fork of linux-libc-headers and instead 
use the suggested method of including the needed files 
from ${STAGING_KERNEL_DIR} in the recipes that need them.

However, I soon realized that what I need are the sanitized 
headers that are generated by running "make headers_install" 
in the kernel sources. So what I then did was to create a 
simple bbclass that generates them for me and makes them 
available for my recipe:

---- %< ------------- kernel-headers.bbclass --------------
DEPENDS += "virtual/kernel"

PACKAGE_ARCH = "${MACHINE_ARCH}"

inherit kernel-arch

KINCLUDES ?= "${WORKDIR}/kernel-includes"

do_compile_prepend() {
	mkdir -p ${KINCLUDES}
	oe_runmake -C ${STAGING_KERNEL_DIR} headers_install INSTALL_HDR_PATH=${KINCLUDES}
}
--------------------------------------------------- >% ----

After that I could simply do 'inherit kernel-headers' and 
'CFLAGS += "-I${KINCLUDES}/includes"' in my recipe to get 
at the sanitized kernel headers.

But, it seems somewhat wasteful for each recipe that need 
those headers to do that. Wouldn't it be an idea to provide 
the sanitized headers in ${STAGING_KERNEL_DIR}/usr/include 
(which would be the default path for make headers_install) 
by default?

//Peter

Re: Sanitized kernel headers

[Bruce Ashfield]

On 13-10-02 09:45 AM, Peter Kjellerstedt wrote:
> In a recent commit
> (http://cgit.openembedded.org/openembedded-core/commit/?id=c27ac156bcaf3193d52f456480947b0cfaef3c72),
> Richard added a big warning about not forking the
> linux-libc-headers recipe to get at specific kernel
> headers for user space. As a consequence I thought I
> should remove our fork of linux-libc-headers and instead
> use the suggested method of including the needed files
> from ${STAGING_KERNEL_DIR} in the recipes that need them.
>
> However, I soon realized that what I need are the sanitized
> headers that are generated by running "make headers_install"
> in the kernel sources. So what I then did was to create a
> simple bbclass that generates them for me and makes them
> available for my recipe:
>
> ---- %< ------------- kernel-headers.bbclass --------------
> DEPENDS += "virtual/kernel"
>
> PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> inherit kernel-arch
>
> KINCLUDES ?= "${WORKDIR}/kernel-includes"
>
> do_compile_prepend() {
> 	mkdir -p ${KINCLUDES}
> 	oe_runmake -C ${STAGING_KERNEL_DIR} headers_install INSTALL_HDR_PATH=${KINCLUDES}
> }
> --------------------------------------------------- >% ----
>
> After that I could simply do 'inherit kernel-headers' and
> 'CFLAGS += "-I${KINCLUDES}/includes"' in my recipe to get
> at the sanitized kernel headers.
>
> But, it seems somewhat wasteful for each recipe that need
> those headers to do that. Wouldn't it be an idea to provide
> the sanitized headers in ${STAGING_KERNEL_DIR}/usr/include
> (which would be the default path for make headers_install)
> by default?

For developers already comfortable with using a previously forked
libc-headers, I don't see much of a problem. There of course is still
a potential issue if these parallel, machine specific headers are
generated from a kernel tree that modifies files which are already
exported and made available via the libc-headers package.

That being said, the risk is actually less in this situation, since
a different include path is required, hence an explicit acknowledgment
that something not quite standard is happening.

I've proposed similar solutions in the past, including installing
the headers into the sysroot along side of the libc-headers in
"usr-alt/", or "kernel-headers/", rather than within the kernel
staging dir, since the staging dir is often tar'd up and added to
things like the kernel-dev package or SDKs .. and if not properly
installed, you can clash with the libc usr/include/linux headers.

But yes, either way, I'm all for doing this once, making them
available in a oe-core "standard" location, as long as it isn't
picked up by default include paths.

If you want to open up something in the bugzilla, we can take care
of this early in the yocto 1.6 cycle, since at this point in 1.5,
we don't want to jiggle much of anything :)

Cheers,

Bruce

>
> //Peter
>