> On 4 Sep 1998, Anthony Ginepro wrote:
> > I thought that was why "pre-install" & "post-install" commands
> > were implemented for in modules.conf.
> > Here's an example with my soundcard and alsa module :
> > ---
> > options snd-sb16 snd_index=1 snd_port=0x220 snd_irq=10 snd_dma8=1 snd_dma16=5
> > post-install snd-sb16 cat /etc/mixer0 > /proc/sound/card1/mixer0
> > pre-remove snd-sb16 cat /proc/sound/card1/mixer0 > /etc/mixer0
> > ---
> > I don't really think we need something else...but maybe I'm wrong.
> >
>
> There are (at least) three problems with the current approach:
>
> 1. When modules are unloaded automatically (automatic reaping by the
> kernel), the pre-remove code isn't run (as modprobe isn't even
> involved). This more-or-less requires that automatic reaping be moved
> out of kernel space, and into userland, where it belongs. (I assume
> your setup works by loading the snd-sb16 module explicitly at boot, and
> unloading it at shutdown; but others may wish for sound to be loaded /
> unloaded using kmod & friends).
Actually automatic reaping doesn't to seem work with my 2.1.x kernel,
so I never noticed it was a problem...anyway when I reboot I always kept my
mixer levels. And *yes*, I my configuration autoloads this modules:
--- alias char-major-14 sndalias snd-minor-oss-0 snd-sb16 alias snd-minor-oss-3 snd-pcm1-oss alias snd-minor-oss-4 snd-pcm1-oss alias snd-minor-oss-5 snd-pcm1-oss alias snd-minor-oss-12 snd-pcm1-oss alias snd-card-0 snd-sb16---> 2. Not every card exports all of its settings via a /proc interface, nor > can it get them back through it. And I'm not sure it's The Right Way, > as /proc-handling code bloats the kernel and is very error prone.
The ALSA driver aims to support FULL /proc configuration,so all settings can be exported easily. I dunno if OSS can do this as well. If it's not The Right Way why do /proc/sys or /proc/pci exist ? There are used to configure the kernel easily from userland with scripts, so it's simple and well tested now.
> 3. Sound settings, in particular, are a problem: we don't want to have the > driver reset mixer settings even for a short while after it's loaded, > as this may cause sound glitches or even damage hardware (too high > volume, for example). So we need these a method for these settings to > be set at module initialization time.
Always with ALSA driver, mixer starts with all channels muted, so we don't have sound glitches...
All I want to proove is that we *already* have a way to configure modules in userspace with the help of modules.conf, but maybe needs some improvement like : 'pre-init' : launch a script just after module is loaded in kernel and before it initialize device.
so that we can do: pre-init sound cat /etc/mixer_levels /whatever_file_keeping_mixer_levels and everybody will be happy...
Of course it's only according to the sound module point of view, and we maybe need other mechanisms for other kind of module (network, parallel devices,...) that I dunno because I don't have any of these.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/faq.html