Hi Charles, > 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. Maybe I'm just missing your point - but I just fail to see how you would be able to offer all the kinds of things people want to boot from (floppy, CDROM, Harddrive, USB Stick, PXE, whatever else might come up soon) without also having to offer a huge number of different initrds (or whtever they would be called at that point). With the additional size of the 2.6 kernel, the whole initrd idea is already becoming difficult (difficult enough that some distros like the RedHat dropped support for booting from floppy), but if we take away the possibility for somebody to boot via floppy and then add the stuff he or she needs to boot from his/her favourite boot media, we're pretty much giving up the "modular approach", in my point of view).
> 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'm all for that - and I guess there's still room for improvement in that area. But in the end, the initial bootstrap code will always need to know how to get to the files it needs for booting, so unless we're willing to probide a "one size fits all" image, we'll always have to decide between either offering all kinds of images for all imaginable uses, and giving people a change to change the setup and back it up again (or just tell them to go away and look someplace else). > 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), Indeed, I agree here too. There are a couple of things that 2.6 kernels offer that I wouldn't want to miss anymore on my desktop boxes, or my servers - but so far, I still have to see things I _need_ on my routers (gigabit or "wimax" (or whatever they decide to call it) might be something at some point). Sooner or later, we'll see new hardware that will only be supported by 2.6 kernels, at which point it will make a lot of sense to think some more about migrating to 2.6, but at the moment, I'd gladly trate stability for being able to use the latest greatest marketing terms for my router (currently, the main advantages I see with 2.6 over 2.4 are with multimedia stuff [low-latency and so on] and with "enterprise stuff" - none of which matters all that much for LEAF). In the end, I tend to agree with Luis. I'm not going to tell anybody to stop discussing new possibilities - but discussion without the ability/willingness to actually do more than just discuss things is pretty much what I contribute to management these days (I spent a fair share of my work time in meetings with people who discuss things they neither know how to do, nor would they be willing to provide the manpower to get it done - they just like discussing things). Maybe that's why I'm very skeptical about the value of discussions all by themselves. Discussing how to solve a problem at hand is perfectly fine, and usually also very useful - but discussing things despite the fact that every participant of the discussion has a different idea of what the actual issue one might be discussing is something else... Again, maybe I just see too much of that kind of thing in my day job, and are therefore unable to see the honest attempt to find the best technological solution for leaf. If that's the case, I sincerely apologize for my cynicism/sarcasm. Martin ------------------------------------------------------- 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
