/etc/modules, alsaconf

/etc/modules
I am planning to modify how the 'zdrv' file works. The concept of "fetching" a module on-demand has limitations, and I am now adopting the approach that all modules must be present in /lib/modules, so nothing has to be fetched. This enables the MODALIAS module loading mechanism to work.

With 4.1alpha1 I experimented with having all modules in the initrd, built-in, and they get moved across to the main filesystem.

With the zdrv file, it was designed so that it could be mounted on '/', like other SFS files, however it has turned out that doing this "on the fly" does not work. Instead, I am going to change the zdrv file so that it will mount directly on /lib/modules, using a loop device. This does not mess around with the unionfs layers.

However, there are some files inside /lib/modules. I have moved DOTconfig-K2.6.25.4 and firmware.dep.2.6.25.4 to /etc/modules. There are some other files inside /lib/modules but they will no longer be needed.

The collection of firmware tarballs is in /lib/all-firmware, and I will relocate that at /lib/modules/all-firmware.

Then, the zdrv file will simply mount directly onto /lib/modules, and can be mounted and unmounted as needed. Ditto in the initial ramdisk.

Have just started implementing this.

alsaconf
The /usr/sbin/alsaconf script used in Puppy has been fairly heavily hacked over the years by me. Last week a 4.00 tester reported that sound did not work, but when that person used the alsaconf script that came with alsa-utils-1.0.16 package, sound worked.

So, I got that script, put in some hacks for it to work better in Puppy, tried it, and lo-and-behold, sound worked for me too. On my laptop, which uses the snd_hda_intel module, sound does not work with some versions of ALSA. I don't recall exactly, but it was working with 1.0.11 I think, stopped working later, came back with 1.0.14, then went away again with the latest as used in pup 4.00, 1.0.16.

Until I ran the alsaconf script that is, then it came back. Now, I see one difference. I had these lines in /etc/modprobe.conf:

alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss

---

Comments

cough* LZMA *cough
Username: Ted Dog
Gee, This would be a perfect fit to use those patch. I recall a quote from an old western movie: "Patches, we don't need no stink'n patches"

kernel sfs
Username: kirk
"I posted the kernel source sfs file for 4.1A here: http://www.puppylinux.ca/tpp/kirk/kernel-src_401.sfs and the md5sum: http://www.puppylinux.ca/tpp/kirk/kernel-src_401.sfs.md5sum.txt I compiled the ATI fglrx 8.5 video driver kernel module with it. Made a package out of it that includes the needed xorg libs. It's here: http://www.puppylinux.ca/tpp/kirk/ATI_fglrx_Pup4.1-8.5.pet

zdrv_xxx.sfs is read only!
Username: pizzasgood
"I see a problem. What if I want to install new drivers? zdrv_xxx.sfs is read-only, so if it's mounted on /lib/modules we won't be able to add new modules to the mix unless we rebuild the zdrv file. Could it be better to mount the file elsewhere, then symlink its contents into /lib/modules? I think the best method of doing that would be to have a script ensure that all needed directories are created, and then only symlink the actual files, and only if the file doesn't already exist. Another script could be run on bootup or after unmounting zdrv to remove any broken symlinks, and maybe any empty directories. Maybe only remove the broken symlinks pointing at zdrv's mountpoint, just in case it's a broken symlink that the user put there for some reason. This way a person can add his own modules or replace one from zdrv with a different version. Of course, I just cooked this up in the last five minutes, so I wouldn't be surprised if there are better solutions out there.

initrd.gz-zdrv
Username: kirk
"How about doing this in the modprobe script to get a module: # zcat /mnt/home/4.1alpha/initrd.gz | cpio -di "lib/modules/2.6.25.4/kernel/crypto/cbc.ko.gz" That takes less than a second on my laptop. Then make a wrapper script for depmod that does this: 1) rm /lib/modules/(uname -r)/modules.* 2) depmod.bin (the real depmod) 3) Use cat to combine the output from the real depmod and /lib/modules/(uname -r)/modules.* that are found in the initrd.gz. It doesn't seem to matter if there are duplicate entries, at least with a few tests I've ran. At first shutdown when the option for copying the pup_401.sfs to your harddrive is given also copy the initrd.gz.

Re: /lib/modules
Username: BarryK
"There are many issues involved here. 'depmod' ignores symlinks. Unless the source is hacked, depmod is going to ignore symlinks to modules that are somewhere else. If you install a new module then run depmod, if there are symlinks inside /lib/modules then you won't get the correct module dependency files. The MODALIAS module loading mechanism requires all modules to be actually present in /lib/modules. When the kernel detects hardware, it creates appropriate entries in /sys, including 'modalias' files (which requires the modules dependency files in /lib/modules/<kernver>). The binary 'modprobe' program can be executed by 'modprobe <modalias>' and it will load the correct module, however that mechanism requires not just the full dependency files to be present but also all the modules. My cumulative experience in all of this has lead me to conclude that all modules must be in /lib/modules, fully present, no symlinks.

Tags: puppy