Rohit Sharma schreef: > Quick questions - Holly. > > When I configure alsa support in my kernel and build modules using > menuconfig and tell kernel to load modules automatically [or do > manual loading using modules.autoload.d] > > 1. Do I still have to enable alsasound service using "rc-update add > alsasound default" ?
Yes; the service does the important job of storing your mixer levels on shutdown and restoring them on boot, as well as actually loading the modules for use. The idea of a loadable module is that the module is loaded when something needs it, rather than just loading because it is available. This is why you have to, for example, compile the modules for your / filesystem statically-- because they have to be already loaded before you need them in the boot process (statically-compiled modules are loaded in the very first "initializing kernel" instructions). Loadable modules, on the other hand, are loaded when something asks for them, like an initialization script (network initialization script to 'need' the network card drivers, X to need the fglrx drivers, firestarter to need the various ip_filter modules, and so forth). Otherwise, you'd have to modprobe the modules before attempting to start the program that needed them to be already in operation before the program could work (like the boot process, which has to read filesystems on a drive and can't stop to load the modules for the filesystem-- which modules, if compiled as loadable modules rather than statically, are themselves on the filesystem that the boot process cannot read because the modules aren't loaded-- before it can read the filesystem to manage the files it needs on that filesystem in order to continue the boot process). So you need something to need the sound modules to load, or else they won't, and that's what alsasound does, too. > 2. Is it a good idea to let the kernel automatically load modules or > use /etc/modules.autoload.d/kernel-2.6 for it? [ Currently I am > using the file instead of kernel [I disabled my onboard i8x0 card in > BIOS to install this CMIPCI one and was skeptic that kernel would > pick up the onboard one. I guess for a correctly configured host, it > woudn't matter]. Well, if you want to do more work when it isn't necessary, you're free to use modules.autoload.d to manage the modules, but you then have to maintain that file. For no reason. Alsasound contacts the kernel to load the modules just fine as long as you've given it a correct range of modules to access. As for your onboard sound, I was afraid of it loading as well when I disabled it and added a new sound card, but the kernel is pretty smart, and just ignored it, especially since I removed all reference to the driver/modules in my ALSA configuration files, and stopped compiling modules for it in the kernel. After all, the kernel can't load a module that doesn't exist :-) . If for some reason that doesn't work for you, you can add the onboard sound modules to /etc/hotplug/blacklist, but that shouldn't be necessary. Really, the kernel does know what it's doing rather well these days; you can definitely give it the benefit of the doubt and trust it first, assuming that it's going to do what it's supposed to, rather than suspecting it of not being competent and assuming you have to manage it doing its job. > > To say the least your response was encouraging. I am in the middle of > an emerge after two months of disconnectivity.... Glad to hear it. Good luck with the next steps. Holly -- gentoo-user@gentoo.org mailing list
