04.07.2015 15:45, kp kirchdoerfer пишет: > Am Samstag, 4. Juli 2015, 15:31:40 schrieb Andrew: >> 04.07.2015 15:14, kp kirchdoerfer пишет: >>> Hi; >>> >>> I almost agree with Erich :) >>> >>> Am Samstag, 4. Juli 2015, 14:56:33 schrieb Andrew: >>>> 04.07.2015 11:34, Erich Titl пишет: >>>>> Hi >>>>> >>>>> Am 04.07.2015 um 09:50 schrieb Andrew: >>>>>> Hi. >>>>>> >>>>>> In most cases probing from squashfs is preferred over loading from >>>>>> moddb >>>>>> - at least, this will not break system after update if it'll require >>>>>> some modules that aren't in moddb (for ex., some ethernet driver). >>>>>> >>>>>> We may add some option to use legacy behavior with sqfs, or we may add >>>>>> fallback behavior with tgz package for hwdetect. >>>>> This would IMHO be a very ugly behaviour. I belived and still believe >>>>> that the sqfs was a more elegant replacement for modules.tgz, and it >>>>> is. You decided to use it also on startup with hwdetect, which makes >>>>> IMHO most of the modules in initmod completely redundant. >>>> This makes moddb completely redundant, and this is leaved only for >>>> systems with small storage + rare cases like custom modules. Initmod is >>>> needed anycase - it's mounted with rootfs, and requires loaded >>>> storage-related modules. >>> Indeed; if we empty moddb, we have to make shure most of the modules are >>> referenced in /etc/modules, so they'll be loaded by hwdtect during boot >>> from sqfs. >> No, they'll be loaded like with filled moddb. >> >>> Will free about 1.8MB on the images, but I believe requires more >>> >>> maintenance cvause we need to keep /etc/modules in sync with kernel >>> modules >>> (netfilter etc). Don't know if wildcards are suppported in /etc/modules. >> netfilter/iptables/shaper modules are in .depend list of corresponding >> packages (<DependsOn> section, lines like 'Module = ipt_*' - yes, with >> wildcards; algorithm earlier was used in getdep.sh). > Seems I saw it, but forgot the changes you've made. So we can start to work > with an empty moddb, but keep it for saving modules after hwdetect or added > by the user? Right. On my 5.2 boxes there's no moddb at all.
>>>>> To me all this looks like we have no clear policy for module handling, >>>>> at least in a transition phase. Just using the sqfs looks like a >>>>> regression to me. >>>>> >>>>> Reducing the size or even making initmod redundant would be great if >>>>> we could achieve that. I believe with the inclusion of sqfs support in >>>>> the kernel this is possible. We should only do hwdetect if sqfs is >>>>> present and definitely not inhibit saving modules in moddb. >>>>> >>>>> I don't want to run hwdetect at each and every boot and there should >>>>> be a boot time selection either just by the presence of sqfs or a >>>>> command line switch. >>>> Will it be enough good to add legacy .tgz handling to hwdetect (so >>>> systems with tgz instead of sqfs will have same behavior as earlier)? >>> I don't think it's necessary to revive tgz; it will just waste disk-space >>> adds code etc.. >>> >>> Saving modules in modbd and get rid of modules.sqfs later and until next >>> update works if I remoce /var/lib/lrpkg/sqfs.modules (the "blacklist"). >>> >>> An idea could be to add configuration option in /etc/lrp.conf (like >>> lrp_SAVE_MODULES) and if set to "yes" hwdetect does not write the modules >>> loaded into the blacklist - waht dou you think? >>> >>> kp >> Ok, we may do this. This shouldn't be too complex. Where this option >> should be (leaf.cfg, kernel boot line, /etc/lrp.conf or somewhere else?). > I think leaf.cfg would be the most obvious place. > > kp > Ok, I'll try to add option to init/hwdetect util in some days. I think that by default we shouldn't save probed modules to moddb. ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
