Hi. 03.02.2016 17:44, kp kirchdoerfer пишет: > Hi all; > > I'll try to summarize the current and proposed status of loading modules as > this raises questions. > > Pls correct me whereelse needed if I missed something or got it wrong. > > This summary is based on 5.2.x, master and new-initrd-6x branch > > > A) The current status > > At the time we do have three mechanisms to load modules, which itself is is a > state of transition. > > 1) First one is to load all hardware related modules during boot in linuxrc > > 2) Next we load(copy??) all modules from /etc/modules - esp. added for modules > which are not hardware-related like tun.ko (openvpn), ppp*.ko etc. > > 3) A third mechanism has been introduced last year to add modules to > load(copy??) for a given Package in buildtool.cfg in the <DependsOn> section > of buildtool.cfg. This concurs with loading from /etc/modules and is intented > to replace the need to add a module for a Package to /etc/modules and have > loaded(copied??) instead "automagically" - like other Packages a Package > depends on. > Although 2) and 3) are similar loading(copying??) from /etc/modules is a > welcome fallback, in case we do miss a module when building a package in > buildtool.cfg. > > As you can see above, I'm not shure if modules in step 2 and 3 are really > loaded or just copied to /lib/modules. > Anyway this works, if we later start packages that need modules, they > DependOn. 2) - modules are loaded to kernel 3) - modules are just copied. they are loaded by software if needed (for ex., iptables modules)
> A major drawback is that this way we do have a lot modules just copied into > the RAM (although compressed). > > Did I get this correct so far? > > B) Proposed status > > Erich invested work to reduce the number of copied/loaded modules in the new- > initrd branch to minimize RAM usage. > He started to build the essential modules from initmod.lrp into the kernel - > that way we can get rid off initmod.lrp at all. While it will raise the kernel > size, it is hoped that we can go wihout having modules as compressed modules > in /lib/modules as well as uncompressed loaded into the RAM. > This effort will buy out even more if we want to support more specialized > architectures/images than today. > > In a second step he replaced the current way to load/copy every module into > /lib/modules with a mimic to work with modules.sqfs and to now > really load required modules into instead insted of copy the compressed module > and load afterwards. > > new-initrd is able to load > a) hardware related modules during boot > b) load modules from /etc/modules > > but does not work with modules defined in <DependsOn> > (/var/lib/lrpkg/*.depmod) > > Instead it usees for shorewall the /etc/shorewall/modules* to oad all modules > required modules with a modification to shorewal[6]l's init files (once again > mount modules.sqfs, load modules and umount ). > > While this works for shorewall[6] with a well-defined configuraton, which > modules to load, and therefor does not load any netfilter/xtables etc module > unndeeded, and keep the necessary size in RAM as small as possible, it fails > to load needed modules of packages that assumes that modules are available > (like openvpn, arptables, ppp*). > > Erich made the proposal to change the init scripts of such packages to mount > modules.sqfs and load whatever required. Good solution. But IMHO we should leave possibility to use old behavior on systems. > Another option could be to modprobe all modules in question from > /var/lib/lrpkg/*depmod, but it will load more modules into than needed. > > I've discussed this with Erich forth and back, each one with better or worse > arguments, but without a proper solution. > > So we decided to move the discussion to leaf-devel (again) to find a proper > solution and to have as much feedback as possible. > > I may have been to short in describing what's possible with new-initrd, and > also to describe the drawbacks - but I want to start a discussion how to deal > with > > a) the current situation to deal with modules > > b) how to keep the advantages of new-initrd, while getting the best of the > work we've done in the past > > Any input/ideas is welcome. > > thy kp > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > > _______________________________________________ > leaf-devel mailing list > leaf-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-devel ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
