Hi Andrew Am 01.12.2015 um 09:46 schrieb Andrew:
30.11.2015 23:44, Erich Titl пишет:Hi AndrewAm 30.11.2015 um 14:16 schrieb Andrew:30.11.2015 13:41, Erich Titl пишет:Am 30.11.2015 um 10:44 schrieb Andrew:30.11.2015 11:11, Erich Titl пишет:Hi Andrew Am 22.09.2015 um 20:02 schrieb Andrew:Hi. Another important target IMHO - merge all important stuff (root.lrp/etc.lrp/config.lrp/other packages that are 100% present in LEAF box) into initrd.Don't do that, initrd is overloaded as it is now,Why you think that using separate packages for that files are better than placing them into initrd? Or you know LEAF usecases when, for ex., root.lrp with all it's dependencies wasn't loaded?That is fine, if you load it from a single .lrp, initrd is IMHO the wrong place.Why? What difference between single big .lrp, and placing all into initrd? IMHO there's only one trouble - with current environment we can't just run 'apkg -u initrd.lrp', but 1) basic things aren't updated too frequently and 2) this is solveable.I am just afraid of overloading initrd, I need to package it with initmod, because grub does not support multple initrd files. ..I think that 850kb instead of 550kb isn't a big difference.What do you consider moving from root.lrp to initd? Why not make a big root.lrp which contains everything for a basic system and leave initrd tiny?This will be a RAM waste, esp. on devices with 32M RAMand it's deps. Because on embedded platforms with small amountof RAM and available MTD device (that is always connected to SoC) it'll be preferrable to use squashfs initrd that is always mounted (+ mount overlayfs on top of it) rather than copy all stuff from it to valuable RAM.Yes, but unless you can access the medium containing the squashfs that won't work.On embedded platform, mtdblock driver will be compiled in kernel - so we'll have access.If we can place initrd on squashfs this is certainly better. The question is here, can we low_level load the squashfs initrd, so we can load the storage and network drivers from there? cheers ETFor embedded platforms, kernel should contain all boot-required modules compiled in.Totally agreed, this may mean we have a number of kernels for various platforms.Yes, of course. Each SoC (or even each hardware platform) will require it's own kernel - like OpenWRT does. And there's no solution to create single kernel that will boot on SoCs from different vendor. Too big difference in chips. And even different SoCs families will require different kernel patches.And SoC network drivers also may be compiled in kernel, notas modules to save some space. Rest of modules (like additional USB network adapters, iptables modules and so on) will be compiled as modules.I suggest to build a new modules.sqfs with the kernel directory level removed and permanently mounted to /lib/modules/kernel. This way we can avoid to have to copy the modules to /lib/modules completely. We just need to run depmod once the squashfs is mounted, then module loading can be done from the squashfs directly and if user specific modules are needed they can either be on an OverlayFS or be written to a subdirectory of /lib/modules.Permanent squashfs mounting IMHO isn't a good idea - this will require permanent underlying device mounting. This is OK when we use mtdblock which contains squashfs - but device's flash size usually 4-8 MB, so there'll be no free place for modules.sqfs on it. Rest of files will be loaded from USB flash, or even from network.
Ahh, you don't like the underlying FS be mounted to access the squashfs file. We could always use a raw partition for this purpose.
This may be done as option - but IMHO it'll be useful only in some rare cases. Because main feature of LEAF - it doesn't require HDD/flash storage that is always mounted.
True, but we could still do that, as /lib/modules is not really needed once the system is running, except for the rare case when you need to load another module. We could mount modules.sqfs, load the modules from there and then just unmount it without copying the module to ram. There would be no modules cluttering valuable ram disk. For the occasional loading of modules we could build a wrapper for modprobe.
Else you may took? for ex., debian,
install it on flash, mount it's root as r/o on boot and use it...
True :-) cheers ET
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
