Messages in this thread | | | Date | Mon, 3 Jul 2006 20:46:47 +0200 | From | maximilian attems <> | Subject | Re: [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/
| |