Re: [leaf-devel] status of modules loading - old, proposed new and questions
Hi KP Just to make it more clear Am 07.02.2016 um 14:09 schrieb kp kirchdoerfer: > Hi; > .. > > 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). I analyzed the case of openvpn All based on a standard 5.2.4 installation SALT# cat /etc/motd LEAF Bering-uClibc 5.2.4 Rev 1 uClibc 0.9.33.2 at SALT Linux 4.1.16-i486 #1 Thu Feb 4 19:09:38 CET 2016 SALT# apkg -l | grep openvpn openvpnz 2.3.9 Rev 2 uClibc 0.9.33.2 SALT# lsmod | grep tun So openvpn is installed, but tun is _not_ loaded SALT# ls /lib/modules/4.1.16-i486/tun* /lib/modules/4.1.16-i486/tunnel4.ko.gz /lib/modules/4.1.16-i486/tunnel6.ko.gz Mhhh... the tun module is not even _copied_ to /lib/modules SALT# ls -l /var/lib/lrpkg/openvpnz.depmod ls: /var/lib/lrpkg/openvpnz.depmod: No such file or directory No surprise, there is no depmod file in openvpnz Package = libcrpto Package = libssl So current analysis shows that despite the pledge of DependsOn, it has not fully been implemented, even one of the most cited packages is not even supported. Please, what are we discussing about here? cheers ET -- 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=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] status of modules loading - old, proposed new and questions
And they should be accessible at least for some time after daemon start (for ex., 5-10 seconds) - daemon may not always load modules at start, it may load modules on demand. And I expect that it shouldn't unload modules. Also, now we are freeing unused modules on device plug out. And for new realization we shouldn't unload modules (else each device disconnect will require manual modules re-probing) or on each connect event we should try to mount storage for 5-10 seconds. 08.02.2016 19:59, Erich Titl пишет: > Am 08.02.2016 um 18:54 schrieb Andrew: >> Modules can be loaded by daemon (for ex. accel-ppp loads needed modules). > Right, so at daemon start the modules need to be accessible > > ET > > > > -- > 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=/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=272487151=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] status of modules loading - old, proposed new and questions
Am Montag, 8. Februar 2016, 13:20:07 schrieb Erich Titl: > Hi KP > > Just to make it more clear > > Am 07.02.2016 um 14:09 schrieb kp kirchdoerfer: > > Hi; > > .. > > > 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). > > I analyzed the case of openvpn > > All based on a standard 5.2.4 installation > > SALT# cat /etc/motd > LEAF Bering-uClibc 5.2.4 Rev 1 uClibc 0.9.33.2 at SALT > Linux 4.1.16-i486 #1 Thu Feb 4 19:09:38 CET 2016 > > SALT# apkg -l | grep openvpn > openvpnz 2.3.9 Rev 2 uClibc 0.9.33.2 > SALT# lsmod | grep tun > > So openvpn is installed, but tun is _not_ loaded > > SALT# ls /lib/modules/4.1.16-i486/tun* > /lib/modules/4.1.16-i486/tunnel4.ko.gz > /lib/modules/4.1.16-i486/tunnel6.ko.gz > > Mhhh... the tun module is not even _copied_ to /lib/modules > > SALT# ls -l /var/lib/lrpkg/openvpnz.depmod > ls: /var/lib/lrpkg/openvpnz.depmod: No such file or directory > > No surprise, there is no depmod file in openvpnz > > > Package = libcrpto > Package = libssl > > > So current analysis shows that despite the pledge of DependsOn, it has > not fully been implemented, even one of the most cited packages is not > even supported. Yes, but that we didn't take care to fully implement the mechanism is not an argument against, but shows just our limited time to keep up with changes. And I for myself didn't take care, cause I knew that a decission with a possible rework about loading modules was mentioned as task for 6.x You may analyze ppp/pppoe instead, where /var/lib/lrpkg/*.depmod provides the necesssry modules and therefor requires no user intervention to load the necessary modules. > Please, what are we discussing about here? We discuss a major change. See ticket 73 from 2012 https://sourceforge.net/p/leaf/tickets/73/ where it all started. In the meantime, we could have closed that ticket, because Andrew provided the code to deal with modules dependencies.. Your proposal is to choose a different solution, which has his own merits. But I do not see, how we can go both ways. Therefor I'd like to get a consensus, about how to proceed. 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=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] status of modules loading - old, proposed new and questions
Modules can be loaded by daemon (for ex. accel-ppp loads needed modules). 08.02.2016 19:32, Erich Titl пишет: > Hi KP > > Am 08.02.2016 um 18:26 schrieb kp kirchdoerfer: > ... >> You may analyze ppp/pppoe instead, where /var/lib/lrpkg/*.depmod provides the >> necesssry modules and therefor requires no user intervention to load the >> necessary modules. > OK, so who is loading the modules, please. LINUXRC does not. > > ET > > > > -- > 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=/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=272487151=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] status of modules loading - old, proposed new and questions
Am 08.02.2016 um 18:54 schrieb Andrew: > Modules can be loaded by daemon (for ex. accel-ppp loads needed modules). Right, so at daemon start the modules need to be accessible ET -- 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=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] status of modules loading - old, proposed new and questions
Am Montag, 8. Februar 2016, 18:32:07 schrieb Erich Titl: > Hi KP > > Am 08.02.2016 um 18:26 schrieb kp kirchdoerfer: > ... > > > You may analyze ppp/pppoe instead, where /var/lib/lrpkg/*.depmod provides > > the necesssry modules and therefor requires no user intervention to load > > the necessary modules. > > OK, so who is loading the modules, please. LINUXRC does not. Doublechecked, you are right :) - it seems not work as I expected, point taken. Thx for your patience... :) Now, what's your idea to deal with openvpn/ppp/pppoe? /etc/modules could be a starting point? Wherever possible using/changing init scripts? 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=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] status of modules loading - old, proposed new and questions
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 > > 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 > > (/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
Re: [leaf-devel] status of modules loading - old, proposed new and questions
Hi KP Am 07.02.2016 um 14:09 schrieb kp kirchdoerfer: > Hi; > .. > > 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). Just to make it clear for anyone. Where does openvpn load the tun module? Where does ppp[oe] load the respective module(s)? I believe they still rely on /etc/modules. > > Another unsolved problem will be what happens to packages that do not have an > init file, but needs modules - like arptable. AFAIK arptable like iptable is not an application by itself, just a collection of utilities. So here the same aplies as in iptables. Currently we use the > 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 mimic? Sure, just like it is now. With the exception of shorewall no application I know of can rely solely on DependsOn, because the current logic _does_not_load_the_modules. ... > > > 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 No, we still use modprobe :-) > > 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. We are running in circles here. The new init either works or not. If it has deficiencies, please show them and then we can try to fix them. If we can't fix them, then I just failed. Please come up with a use case for the necessity of the DependsOn logic. cheers ET -- 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=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] status of modules loading - old, proposed new and questions
04.02.2016 08:49, Erich Titl пишет: > Hi Andrew > > Am 03.02.2016 um 22:56 schrieb Andrew: >> 03.02.2016 22:47, Erich Titl пишет: >>> Hi Andrew >>> >>> Am 03.02.2016 um 19:03 schrieb Andrew: Hi. >>> ...>> > 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. >>> What behaviour would you like preserved? >>> >>> cheers >>> >>> ET >>> >> Copying all modules specified in .depmod (or loaded by >> autoprobing/probing /etc/modues) into /etc/modules > Copying does not make sense, as this is exactly what we want to get rid > of. Autoprobing is preserved as is handling of /etc/modules. In case an > application needs additional modules, they are easily pulled from > modules.sqfs, which can be made available in the init script. > > cheers > > ET I mean not to preserve old behavior for all cases. I mean to leave possibility to enable old behavior via some flag.. -- 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=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] status of modules loading - old, proposed new and questions
03.02.2016 22:47, Erich Titl пишет: > Hi Andrew > > Am 03.02.2016 um 19:03 schrieb Andrew: >> Hi. >> > ...>> >>> 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. > What behaviour would you like preserved? > > cheers > > ET > Copying all modules specified in .depmod (or loaded by autoprobing/probing /etc/modues) into /etc/modules -- 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=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] status of modules loading - old, proposed new and questions
Hi Andrew Am 03.02.2016 um 19:03 schrieb Andrew: > Hi. > ...>> >> 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. What behaviour would you like preserved? cheers ET -- 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=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] status of modules loading - old, proposed new and questions
Hi Andrew Am 03.02.2016 um 22:56 schrieb Andrew: > 03.02.2016 22:47, Erich Titl пишет: >> Hi Andrew >> >> Am 03.02.2016 um 19:03 schrieb Andrew: >>> Hi. >>> >> ...>> 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. >> What behaviour would you like preserved? >> >> cheers >> >> ET >> > Copying all modules specified in .depmod (or loaded by > autoprobing/probing /etc/modues) into /etc/modules Copying does not make sense, as this is exactly what we want to get rid of. Autoprobing is preserved as is handling of /etc/modules. In case an application needs additional modules, they are easily pulled from modules.sqfs, which can be made available in the init script. cheers ET -- 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=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] status of modules loading - old, proposed new and questions
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 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 > (/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=/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
