Hello Mike, Charles, Still only have webmail, so I hope it will show up on the list
> This feature might be useful in making a very small initial ramdisk image > for leaf that 'bootstrapped' the full LEAF system, and would not require > a C library of it's own (instead using klibc and essentailly making direct > kernel calls). You'll never be able to run bind or sendmail this way, > but being able to run a simple shell (or other script processor like > forth, lua, etc.) and do things like extract tar files to build a root > filesystem image would be all we'd need. > This is what I mean with redundant, you would need a shell (and other programs) in the initramfs (pre-init) and in userspace which isn't the same one. So you need the space for a klibc compiled shell in the initramfs and an other (uClibc/glibc) compiled shell in root.lrp (or so), while currently we use one shell which is both used for pre-init (linuxrc) and userspace. It isn't possible to use the klibc initramfs programs in userspace (AFAIK), which would be pointless anyway because the klibc versions are/should be very limited in functionality/size. For Mike: There are ofcourse images of ~1.5 Mb which contain an initramfs and 2.6 kernel, but they don't contain all the programs we have in such an image ;) But I agree, the initramfs approach would make a technical cleaner implementation. But it also means (because of redundancy and a bigger kernel (2.6)) a bigger base image. I also don't see a lot of real advantages for our case yet. Eric Spakman ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
