lkml.org 
[lkml]   [2006]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [klibc] klibc and what's the next step?
On Mon, Jul 03, 2006 at 02:30:45PM -0400, Rob Landley wrote:
> On Wednesday 28 June 2006 8:04 pm, Roman Zippel wrote:
> > If you are concerned about this simply keep the whole thing optional.
> > Embedded application usually know their boot device and they don't need no
> > fancy initramfs.
>
> Actually, a lot of embedded applications like initramfs because it saves
> memory (a ram block device, a filesystem driver, and filesystem overhead.)
> Don't use embedded applications as a reason _not_ to do this!
>
> BusyBox has had explicit support for initramfs (switch_root) for several
> versions now. I pestered HPA about building a subset of BusyBox against
> klibc (and cross-compiling klibc for non-x86 platforms) at the Consumer
> Electronics Linux Forum, but haven't had time to follow up yet.
>
> Rob

well but busybox is big nowadays and generally compiled against glibc.
i'm quite eager to kick busybox out of default Debian initramfs-tools
to have an klibc only default initramfs. those tools are needed atm,
and there is not enough yet. afaik suse adds sed on klibc with a minimal
patch and we'd liked to have stat, kill and readlink on klibc-utils.

how about busybox on klibc?

--
maks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-07-03 20:49    [W:0.114 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site