RE: [leaf-devel] 2.6.x kernel support?
On Thu, 2005-08-18 at 23:45, [EMAIL PROTECTED] wrote: It's not very trivial to move to initramfs. Currently we use busybox in initrd which is compiled against uClibc, initramfs is using a method off pre-init programs which must be compiled against klibc. This means having the same type of programs compiled against klibc (which can't be busybox, because that won't be compiled against klibc) in initramfs and userspace programs (busybox) compiled against uClibc (or glibc in the case of plain Bering). Eric, I'm seeing people use initramfs with busybox. From what I understand either uClibc or klibc can be used with initramfs. Google string: initramfs busybox http://sourceforge.net/mailarchive/forum.php?thread_id=7934561forum_id=5348 Google string: initramfs uclibc klibc http://www.redhat.com/archives/dm-devel/2004-September/msg8.html Implementing initramfs would mean a lot of redundancy and added size. Besides not all programs we need in pre-init have a klibc version (like makedevs f.e.). I'm not understanding how this change would introduce redundancy. Of course, size is always a concern. We already use ramfs b.t.w. But what is currently the real benefit of initramfs to LEAF? The lwn article sums up the benefits, but I'm still looking for a better overview of the features/benefits. Initramfs arrives http://lwn.net/Articles/14776/ The combination initramfs and kernel 2.6 makes the distro 50% bigger. Have you tried it? I'm seeing boot images from other projects that are approximately 1.5M. Another interesting klibc and initramfs link: http://fxr.watson.org/fxr/source/Documentation/early-userspace/?v=linux-2.6.9 -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
RE: [leaf-devel] 2.6.x kernel support?
On Fri, 2005-08-19 at 08:48, Mike Noyes wrote: On Thu, 2005-08-18 at 23:45, [EMAIL PROTECTED] wrote: We already use ramfs b.t.w. But what is currently the real benefit of initramfs to LEAF? The lwn article sums up the benefits, but I'm still looking for a better overview of the features/benefits. Initramfs arrives http://lwn.net/Articles/14776/ An initramfs howto http://www.vas.nu/pipermail/klibc/2005-August/00.html -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Re: [leaf-devel] 2.6.x kernel support?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: | On Thu, 2005-08-18 at 23:45, [EMAIL PROTECTED] wrote: | We already use ramfs b.t.w. But what is currently the real benefit of | initramfs to LEAF? | | The lwn article sums up the benefits, but I'm still looking for a | better overview of the features/benefits. To me, it looks like the new initramfs would make it possible to do something like the old LRP patch (which allowed the kernel to use a tar.gz file as an initial ramdisk image) without requiring a kernel patch. It also looks like a handy way to solve various boot-strap problems (like getting a kernel with built-in RAID to look for RAID images *AFTER* some external module is loaded). A lot of this stuff is currently (at least circa 2.2/2.4, which I'm more familiar with) kind of 'hacked' into the kernel, and if your boot sequence is particularly odd, you might have to patch the kernel (or load an excessively large initial ramdisk). 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 would eliminate the 'special' file that has existed in LRP/LEAF since the beginning (ie: root.lrp or initrd.lrp), replacing it with a (hopefully) standard chunk of init code that was simply linked with the kernel. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDBhfRLywbqEHdNFwRAmVaAKC4ctI4urM+d2fudhAHPB6kPow07gCfeN8c 9COK9Mms7v+4FAAzqVYnw3k= =fP/3 -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
Re: [leaf-devel] 2.6.x kernel support?
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
Re: [leaf-devel] 2.6.x kernel support?
-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
