Re: initramfs for /dev/console with udev?

[Martin Schlemmer <azarah@nosferatu.za.org>]

[-- Attachment #1: Type: text/plain, Size: 2550 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]