Re: initramfs for /dev/console with udev?

From: Martin Schlemmer
Date: Fri Nov 04 2005 - 16:36:11 EST


On Thu, 2005-11-03 at 15:29 -0600, Rob Landley wrote:
> On Thursday 03 November 2005 13:57, Roland Dreier wrote:
> > > On Thursday 03 November 2005 12:51, Robert Schwebel wrote:
> > > > [...] klibc didn't compile for ARCH=um.
> > >
> > > I repeat my question: what is it that didn't compile, klibc or the
> > > kernel?
> >
> > come on, dude -- how much clearer can he be?
>
> Ah, I see. The linux kernel headers you feed it were from a kernel compiled
> with ARCH=um. Right. It's been a while since I tried feeding any libc
> actual kernel headers. (I build uClibc against the cleaned up userspace ones
> here: http://ep09.pld-linux.org/~mmazur/linux-libc-headers/ .)
>
> It's also been a while since I played with klibc, and I notice that it doesn't
> work with Maszur's headers. (It sort of works, with lots of warnings, until
> about halfway through when it wants to touch "asm/signal.h", when Maszur's
> just has linux/signal.h, and symlinking the two still isn't happy because
> sigset_t is never defined... In klibc there's definitions for ia64, sparc,
> and parisc. But nothing for x86...
>
> Ok, checking 2.6.14/include/asm-i386 it's an unsigned long, so typedef that...
> Nope, still not happy, wants numerous other symbols now... Okay, try
> grabbing asm-i386/signal.h from libc... And asm-generic/signal.h which
> _that_ includes... And now there's a "previous declaration of 'wait3"'
> conflicting. Beautiful...)
>
> Ok, I remember why I stopped playing with klibc now. It's still deep in
> alpha-test stage, requires way more incestuous knowledge of the kernel
> headers than anything not bundled with the kernel itself has any excuse for,
> and I'm still not sure what advantage it claims to have over uClibc except
> for being BSD licensed.
>

Well, apparently the plan is to eventually bundle it with the kernel if
not mistaken. Also, it have seen a stable release, and it works well
for what it was intended for, and still have a less footprint than
uClibc if space is really an issue.

> If you have to make it work, I'd suggest extracting a fresh kernel tarball, do
> "make allyesconfig" (without ARCH=um), and use _those_ headers. Or just
> accept that it doesn't work and try uClibc. :)
>

It does work, just need to be fixed up for ARCH=um compiled kernel. I
did a quick hack to do this, but HPA don't like it (and I do not blame
him). Can be found here:

http://bugs.gentoo.org/attachment.cgi?id=67478


--
Martin Schlemmer

Attachment: signature.asc
Description: This is a digitally signed message part