20.09.2014 22:16, Erich Titl пишет: > Hi Andrew > > at 20.09.2014 20:13, Andrew wrote: >> 20.09.2014 14:07, Erich Titl пишет: > ... >> Right. Modules aren't userland. So modules are splitted from userland >> initrd. > I would probably argue that initrd isn't userland at all in my mindmap. > For me initrd is a way to allow a system to be booted and IMHO every > trace of it should disappear in the later boot process. But again, this > is just an opinion. Initrd - is userland stuff. There is no difference how we obtain a rootfs at boot - by mounting partition or by using any kind of ramdisk (initrd/initramfs). In any case it contains just a minimal piece of base system.
>>> 2) for >>>> embedded platforms where there is a single userland for arch, and >>>> multiple kernels (even with different versions - if there is a >>>> proprietary patch w/o ports to other versions, and even w/o boot-time >>>> modules for some platforms - if there is a fixed configuration of >>>> boot-time modules, they may be linked into kernel as static). >>> If we had that there would be no need for initmod. >> Right. For one platform. Another platform with same arch (for ex., >> ARMv7) can be booted from SD card/USB - and will have modules (because >> USB drives aren't necessary). So it'll be good to have universal initrd, >> and initmods for different platforms (if they are needed). >>>> Also it helps to easily update userspace w/o kernel or kernel w/o >>>> userspace (they are almost independent now). >>> As they should be.... but I iterate here, modules are not userland ( I >>> have been made aware of this on this proper list ;-) >>> >>>> If loader doesn't support multiple initrd, 2 pieces can be easily >>>> concatenated into one w/o repacking. >>> I understand the idea of separating the kernel from userland, but >>> modules are alway kernel dependent. >> Right, and they are also separated from userland. Now you can just place >> kernel with initmod and moddb.lrp/modules.tgz into your distro - and >> voila, you have old stable userland with bleeding-edge kernel. >>> Even building multiple different self contained initrd for single >>> kernels are no problem as we have a initrd build procedure which may >>> vebuild multiple different architecture initrd files. >>> >>> As you say, as they are cpio archives they can easily be put together, >>> so why not just do it. >> cpio is useful for x86; for embedded with on-board flash - we even may >> use squashfs with tmpfs on top (for saving valuable RAM). I think this >> will be done in 5.2 > Then it might be more difficult to fix it if needed. I would just be > glad if leaf was not such a moving target, so I could get some > development done. > . There winll be no big difference - just additional option to initrd format for platform, and handling squashfs root if it's present. >> Also, almost all boot loaders suport multiple ramdisks. So I don't think >> that it's actual trouble. > Mhhhh... I have not seen this for grub, but then I am not using grub2 > need to investigate. > > cheers > > Erich Grub (at least latest versions) supports multiple initrds: http://forum.slitaz.org/topic/grub4dos-usbflash-slitaz-30-is-ok-slitaz-40-dont-boot-rootfsgz-x4 Grub2 - now also supports: http://savannah.gnu.org/bugs/?35238 ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ------------------------------------------------------------------------ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
