-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [EMAIL PROTECTED] wrote:
| 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. I generally agree with your analysis. Using the initramfs system doesn't make sense for LEAF as it stands now. I would, however, be in favor of using a very powerful, but very small 'shell-like' scripting language (ie: forth) in the initramfs, with the 'applications' being scripts rather than biaries, which is what would make this idea attractive (at least to me). The downside is utilities like tar and gunzip would have to be coded in forth, which I haven't been able to find (or had the spare time to write). I think the entire extra 'footprint', including code to do tar, gunzip, and the forth interpreter itself could be squeezed into maybe 25K or so (assuming no re-use of the application scripts), meaning the 'redundancy' issue wouldn't be that bad, even for a floppy system. If you elected to reuse some of the scripted code, you'd only need a re-compiled interpreter for the appropriate libc, which for forth would probably mean 10-15K of 'redundancy'. ...of course, the probability of this actually happening is pretty close to zero (unless I somehow become independently wealthy!), but I still think it would be cool... - -- Charles Steinkuehler [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDBlbULywbqEHdNFwRAnLCAKChLtlI9drIqDN9zgUebloC2L6g7gCg3F3L Mu/XxB1VWh7XxrRsKhulVbM= =ajCI -----END PGP SIGNATURE----- ------------------------------------------------------- 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
