Hi; Am Mittwoch, 3. Februar 2016, 20:03:19 schrieb Andrew: > 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. > >
I don't think we can't make this a valuable decision. Just adding more code and more options to load modules will increase maintenance work and will be confusing in the future. If we do not copy modules during boot, we have to make shure that for example shorewalls init code calls the helper script mount_module and load modules from modules.sqfs. This is unneeded if we load the modules during boot. If we now want to support both ways to load modules, we will have all the modules right in place, but during shorewall start, it will still mount modules.sqfs and and load modules... and this is true for other packages as well (openvpn, ppp/pppoe and so on). Another unsolved problem will be what happens to packages that do not have an init file, but needs modules - like arptable. Currently we use the <DependsOn> section in buildtool.cfg, and this makes shure we do load the modules needed for arptables, with Erichs approach this does not work any more. So I see no way to keep both approaches side-by-side. Is there a way we can avoid copying modules into /lib/modules, but still using the <DependsOn> mimic? I know that we will have still more than the absolutely necessary modules in RAM, but still using less RAM than to have all modules in /lib/modules (compressed) plus the needed one uncompressed modporobed? Unfortunately the newinitrd branch mixed also 1) get rid of initmod by built the modules needed to noot into the kernel 2) change the way we load modules I suggest we seperate those two changes from each other. Therefor we can have the benefit of moving hardware from initmod into kernel and independent from the decision how to work with remaing modules. 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=272487151&iu=/4140 _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
