-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Luis.F.Correia wrote:
| Is this whole conversation about loading to ram, using initramfs or any | other kind relevant | to the current branches of LEAF? Sure! If nothing else, the discussion of tmpfs and duplication of data in RAM is (hopefully) enlightning. | The way I see it, the team i'm part of has already analysed the implications | of switching over to 2.6 kernels, including the need for a new initial | filesystem. For several reasons we have already gave to the community, we | have decided that for now, 2.6 and all that goes with it, is not really a | great improvement. | | Which means that we (Bering-uClibc Team), are going to continue supporting a | bootable floppy version, using a basic set of a complete, stable production | grade router/firewall. | | For me personally that is a goal to maintain as long as possible, have a | floppy based firewall. | | Altough I don't use floppy-based setup any longer, I still feel that if we | make all efforts to keep supporting it, we will maintain focus. Having a | larger boot media will lead to all sorts of excesses... Indeed...I stopped booting off a floppy ages ago, but I still think it's crutial to support a floppy-based boot image if for no other reason than to avoid bloat. As it stands, "bloat" is an option the end user must actively choose (by adding various LRP packages) rather than something forced by the base system. It's almost always easier to add more stuff, than to try and remove things from a working environment. | Still, one idea from Erich was retained in my mind, and has also lurked in | my ideas from time to time, which is the firmware thing... | Discussing this will open a whole new can of worms, what should be | considered basic and essential? Who will have the power to decide which | stays in the firmware or not? | | We don't want to loose the modular design we have now. Not being able to | backup the initramfs for example is not a very nice thing. I'm all for modular. Not being able to (easily) backup the initramfs image is (in my opinion) not a serious problem, assuming the boot process changes as well. I envision the initramfs as containing only that code required to build a root filesystem image, or roughly incorperating the functionality of the existing /linuxrc script. To make sense, these features would have to be coded in something very small (ie: no big C library required) so the extra space could be justified (I'd give up 10-50K to have a powerful scripting language like forth or LUA avaialble at runtime!). If the initial building of the root filesystem image isn't handled by a small, stand-alone script(s), I don't think using initramfs really buys us anything vs. using the existing (conventional) ramdisk based startup. | I think we may be loosing too much time discussing stuff with little or no | result... The central DB design comes to my mind for example... :) | So, unless someone has a good small footprint design using the latest | available techologies, providing the same capabilities we have now, lets | leave the matter for now. I agree we've pretty much wrung out the initramfs issue. I think there could still be reasons to want to migrate to a 2.6 kernel (hardware support, new features, etc), but I don't think the initramfs issue makes the 2.6 kernel a lot more desireable than 2.4 (at least until someone actually *WRITES* some small, script-based boot-strap code that would make it useful to LEAF). - -- Charles Steinkuehler [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDDOdOLywbqEHdNFwRAtjwAKCRnocpXi5VVyHqCNSWfoz/UZryKQCg4+3h Y9Rt1PNPtR2mAL+1UwIX1MY= =qKnz -----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
