Re: [leaf-devel] modutils testing
K.-P. Kirchdörfer wrote: Hi; in latest linuxrc archiv from Charles are changes to modutils and modules loading, esp. if you use other medias as a single floppy. Again we find the bang commands from Dachstein. The Bering-uClibc team had a look at it and decided for next version to stay with the Bering way, unless this discussion brings up some new aspects and arguments. We saw the advantages of the Charles changes (it's flexibel to choose modules dir, the device (cdrom) is not always mounted). The advantages of the Bering way are from our view: - easier /etc/init.d/modutils code - easier from a user perspective (it's most automagic) - there is a link for the correct modules dir (lib/modules/2.4.24) In practice we found problems like the following: insmod throws an error with new modutils: /lib/modules/2.4.24. not found loading module Shure cosmetic, but can be confusing (solved in Bering with the correct link - either to cd or /lib/modules) I don't think the full version of insmod behaves this way, so IMHO this is a bug with busybox (likely stemming from the fact that I think BB is folding in modprobe functionality with insmod). If we need a symlink from /lib/modules/kernel-ver, IMHO it should only point to /lib/modules and not to the CD-ROM. Further do the bang commands only work during boot (when /etc/init.d/modutils is called) - afterwards the cd will be umounted and the cdrom/lib/modules/2.4.24 is not available anymore. This is problem for example with ipsec. During ipsec restart the module is unloaded and reloaded - of course that fails, if the device is not mounted. It's necessary to store ipsec.o in modules.lrp - but the the seamless and easy usage of a complete modules tarball on a mass storage is worthless. I run IPSec with no problems. Maybe we have not fully understood how to work with Charles chnaged modutils behaviour and the issues above can easily solved, maybe a few changes in Charles code and it's becoming the best of both worlds... IIRC, the IPSec scripts don't try to load any modules unless IPSec support isn't already enabled. I simply load all required modules at boot. If you really want, you can add new modules to /etc/modules at runtime and simple svi modutils to load them. I understand the difference of opinion here, but would like to make one request: - Can the Bering crew make sure any code that mounts (and leaves mounted) a CD-ROM or other device containing modules be restricted to the modules package? This would allow me (and anyone else who doesn't like permanently mounting the CD-ROM and symlinking to it) to replace just the modules package with a custom version. I really don't want to have to run a hacked version of initrd to leave the CD-ROM unmounted. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] modutils testing
Hello Charles, IIRC, the IPSec scripts don't try to load any modules unless IPSec support isn't already enabled. I simply load all required modules at boot. If you really want, you can add new modules to /etc/modules at runtime and simple svi modutils to load them. There are other programs that depend on modules in the /lib/modules/kernel-version/ directory. We don't use them yet but modprobe/depmod and hotplug in combination with pcmcia kernel modules all expect the modules in the standard directory. I understand the difference of opinion here, but would like to make one request: - Can the Bering crew make sure any code that mounts (and leaves mounted) a CD-ROM or other device containing modules be restricted to the modules package? This would allow me (and anyone else who doesn't like permanently mounting the CD-ROM and symlinking to it) to replace just the modules package with a custom version. I really don't want to have to run a hacked version of initrd to leave the CD-ROM unmounted. Can you help us with a piece of code that can be added in modutils to make it possible to mount a device containing modules? Or do you have an other idea to keep the /lib/modules/kernel-version/ directory and mount/umount the modules device on request? Eric Spakman Member of the Bering-uClibc crew --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] modutils testing
Eric Spakman wrote: Hello Charles, snip I understand the difference of opinion here, but would like to make one request: - Can the Bering crew make sure any code that mounts (and leaves mounted) a CD-ROM or other device containing modules be restricted to the modules package? This would allow me (and anyone else who doesn't like permanently mounting the CD-ROM and symlinking to it) to replace just the modules package with a custom version. I really don't want to have to run a hacked version of initrd to leave the CD-ROM unmounted. Can you help us with a piece of code that can be added in modutils to make it possible to mount a device containing modules? Or do you have an other idea to keep the /lib/modules/kernel-version/ directory and mount/umount the modules device on request? I'm not clearly understanding what you want. If you want to dynamically mount something under user control, refer to the 'bang' command processing in my version of /etc/init.d/modutils. If you just want to mount a CD and leave it mounted (ie: 'classic' Bering behavior), just mount the device and make a symlink to it. The original Bering /linuxrc script looks for /lib/modules on all mounted PKGPATH devices. This functionality could be replicated in modutils, but I'd probably just test for the existance of /dev/cdrom (and maybe leave a commented definition in /etc/init.d/modutils so folks could enter a different device if they're booting off HDD, flash or some other media). I.e: something like (untested): # Change this if necessary MODDEV=/dev/cdrom MNTDIR=/cdmnt if [ -b $MODDEV ] mount -r $MODDEV $MNTDIR ln -s $MNTDIR/lib/modules /lib/modules/`uname -r` fi ...of course, there are lots of 'corner cases' to consider, such as: - What happens if you want to keep your HDD/Flash/whatever mounted at runtime (lots of reasons to do this, maybe to use for persistent logs, maybe to store web content for a small web server, etc). If you want to symlink /lib/modules/kernel somewhere else, the next time you reboot, your symlink will get clobbered by the auto-generation stuff, above. IMHO, the /lib/modules/kernel symlink, if present, should be part of the modules package (ie: not dynamically created), so users can point it somewhere else if desired. Also, to me this whole discussion is somewhat pointless. I would strongly argue that LEAF distributions can *NOT* be assumed to have the full modules heirarchy (including modules.dep, etc) that you would normally find on a full linux install. If there are programs that rely on this structure to be present, they will need to be modified to work with LEAF. This leaves 'large-format' LEAF systems, which may happen to have a full modules tree, as a special case of the simpler default system which only has /lib/modules/handful of files. I'm more interested in making the full modules directory easy to access in a similar method to the default accessing of files in /lib/modules than I am in trying to duplicate the full-blown modprobe functionality of a full disto. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] modutils testing
Hello Charles, snip IMHO, the /lib/modules/kernel symlink, if present, should be part of the modules package (ie: not dynamically created), so users can point it somewhere else if desired. Thinking about it, maybe the easiest solution is indeed just add an user adjustable symlink in /etc/init.d/modutils. Also, to me this whole discussion is somewhat pointless. I would strongly argue that LEAF distributions can *NOT* be assumed to have the full modules heirarchy (including modules.dep, etc) that you would normally find on a full linux install. If there are programs that rely on this structure to be present, they will need to be modified to work with LEAF. This leaves 'large-format' LEAF systems, which may happen to have a full modules tree, as a special case of the simpler default system which only has /lib/modules/handful of files. I'm more interested in making the full modules directory easy to access in a similar method to the default accessing of files in /lib/modules than I am in trying to duplicate the full-blown modprobe functionality of a full disto. -- Charles Steinkuehler [EMAIL PROTECTED] I fully agree with you about that LEAF distributions can not be assumed to have the full modules hierarchy and I myself only have a minimal set of modules available on my router. But I don't think the whole discussion is pointless, looking at the the ip_conntrack modularization you need the following modules available in modules.lrp (and /etc/modules, in the correct order!): ip_conntrack ip_conntrack_ftp ip_conntrack_irc iptable_nat ip_nat_ftp ip_nat_irc ipt_MASQUERADE ipt_REDIRECT ipt_conntrack ipt_helper ipt_state Modularizing all of the kernel netfilter items will make this list even longer. Also other items in the kernel are getting more dependencies, like a lot of NIC drivers now need MII and crc32 (kernel 2.4.24). It's difficult (but doable) to find the correct modules and dependencies, but it gets more and more complicated to not make mistakes with adding them in /etc/modules and keeping the correct order, even with small LEAF systems. One possible solution for this is using kmod/modprobe/depmod and let depmod create the dependency files on-the-fly, so only for modules that are added by an user in modules.lrp. But maybe there is a better solution, or the problem isn't as big as I think :-) Eric Spakman --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] modutils testing
* Charles Steinkuehler [EMAIL PROTECTED] [2004:05:10:11:17:09-0500] scribed: snip / IIRC, the IPSec scripts don't try to load any modules unless IPSec support isn't already enabled. I simply load all required modules at boot. If you really want, you can add new modules to /etc/modules at runtime and simple svi modutils to load them. I understand the difference of opinion here, but would like to make one request: - Can the Bering crew make sure any code that mounts (and leaves mounted) a CD-ROM or other device containing modules be restricted to the modules package? This would allow me (and anyone else who doesn't like permanently mounting the CD-ROM and symlinking to it) to replace just the modules package with a custom version. I really don't want to have to run a hacked version of initrd to leave the CD-ROM unmounted. As a longtime Dachstein-CD user, with dozens of deployed boxen, I cannot stress strongly enough how much I *DO* concur with Charles. How difficult can it be to copy those needed modules from the CD modules directory to /etc/modules at bootup? Since not all modules will need this facility, /etc/modules should be kept to a minimum size. At least from my experience with DCD, system memory is never a shortcoming, so copying *ALL* modules to /etc/modules would not hurt my feelings any. However, keeping CD always mounted is definitely a no-no in my book. Just my 2? . . . -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- signature.asc Description: Digital signature
