Hi Erich; (moved to leaf-devel, where it IMHO belongs to)
Am Samstag, 20. September 2014, 21:16:32 schrieb 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. > > >> 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. Being a "moving target" depends: 2.x has been around for more than three yrs (see FRS) 3.x also for more than three yrs (also from FRS) 4.x started in March 2010 and the last version has been built in March 2013 5.x started in October 2011 and we are still working on it. I agree we had changes in the infrastructure during the cycles (CMS etc, but mostly because it was needed, than by will). YMMV kp > > > 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-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
