Date:	Fri, 25 Feb 2011 04:21:37 -0800
From:	Mike Waychison <mikew@...gle.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	klibc@...or.com, maximilian attems <max@...o.at>,
	linux-kernel@...r.kernel.org
Subject: Re: [klibc] [PATCH] build: Define __EXPORTED_HEADER__

On Fri, Feb 25, 2011 at 2:40 AM, Arnd Bergmann <arnd@...db.de> wrote:
> On Friday 25 February 2011, Mike Waychison wrote:
>> On Thu, Feb 24, 2011 at 6:19 AM, Arnd Bergmann <arnd@...db.de> wrote:
>> > On Thursday 24 February 2011, Mike Waychison wrote:
>> >> The kernel header guard to ensure that headers aren't included from
>> >> userland moved in commit 69c8f52b.  This causes the following message to
>> >> be emitted when building klibc (which is designed to use kernel headers
>> >> explicitly):
>> >>
>> >> /usr/local/src/git/linux-2.6//include/linux/types.h:13:2: warning: #warning "Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders"
>> >>
>> >> In order to silence this warning, make sure we define
>> >> __EXPORTED_HEADERS__ when building klibc userland.
>> >>
>> >> Signed-off-by: Mike Waychison <mikew@...gle.com>
>> >
>> > Well, klibc uses the kernel headers, but I don't think it's a good idea
>> > to use them directly without make headers_install. Since klibc also
>> > doesn't set -D__KERNEL__, the result should be the same, except that
>> > it makes sure not to use any headers that are meant to be internal.
>>
>> I'm not sure I follow.  The warning happens when __KERNEL__ isn't set.
>>
>> Also, the build for klibc explicitly supports using kernel headers
>> without installing them first via setting KLIBCKERNELSRC.
>
> My point was that klibc should perhaps no longer support this. When klibc
> was initially written, we did not have a way to install kernel headers and
> distros shipped a set of hand-crafter modified kernel headers. This is no
> longer the case since the kernel headers now work for all other libc
> implementations after installing.
>
> Is there still any benefit in allowing klibc to be built without
> installing the headers?

Well, it's useful for users (like us) that have environments where we
build a single vmlinux image given upstream kernel.org linux and klibc
trees.

> For instance, it should be easy to change the klibc build process from
> requiring to link to the kernel source to automatically installing the
> kernel headers into the klibc object directory.

I'm not against this idea, but is this something that works (and that
people can actually do given the state of the klibc tree at this
point)?

Maybe I don't understand what benefit is had by having a separate
install_headers step that does not much more than copy headers from
the kernel source tree into the klibc object tree as part of the
vmlinux build.

I believe the original motivation of klibc was to maintain a minimal
libc implementation that would mature to the point where we are
capable of building userland binaries in the kernel source tree (so
that some hairy legacy functionality currently implemented in
kernel-space could be cleaned up and moved into early-userspace
targets). I don't know why this effort has subsided, though I can
imagine that lack of will and time were large factors.

What you are proposing seems to me like a step towards giving up on
this noble goal :(

*sigh* At the other end of the spectrum is the fact that we now build
userland targets out of the kernel source tree, but that seems to be
more of a convenience-in-versioning issue than anything else. The
build environment has become pretty reliant on there being a whole GNU
based LSB environment setup for userland, which on a per-unit basis
isn't the de-facto standard anymore.  It'd be nice to hit some middle
ground here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists