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. > >> >> 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. . > 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 ------------------------------------------------------------------------------ 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/
