Hello Charles,<snip>
I understand the difference of opinion here, but would like to make one request: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?
- 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.
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
