Alan Cox wrote:
> Add a 'preserved' tag for one section of module memory. On load look up the
> data, if its from this boot memcpy it into the module. On unload write it
> back to disk. No kernel code needed.
I like! No kernel code, yet no races or delay.
As written that removes the
Alan Cox wrote:
Add a 'preserved' tag for one section of module memory. On load look up the
data, if its from this boot memcpy it into the module. On unload write it
back to disk. No kernel code needed.
I like! No kernel code, yet no races or delay.
As written that removes the possibilities
> > eth0pegasus
> > nopersist eth0
> > post-install eth0 /usr/local/sbin/my-dhcp-stuff
>
> So, in short, this is already done perfectly well in userspace without some
> sort of Registry-style kernelside hack?
Thats the idea. Once the rmmod code can read back values the cycle is complete
Alan Cox wrote:
>
> > In the NIC example, I might well want the DHCP client to run whenever I
> > activate the card. Bringing the NIC up with the old configuration - which, with
> > dynamic IP addresses, could now include someone else's IP address! - is worse
> > than useless.
>
> You'll notice
On Tue, 07 Nov 2000, Alan Cox wrote:
> > In the NIC example, I might well want the DHCP client to run whenever I
> > activate the card. Bringing the NIC up with the old configuration - which, with
> > dynamic IP addresses, could now include someone else's IP address! - is worse
> > than useless.
> In the NIC example, I might well want the DHCP client to run whenever I
> activate the card. Bringing the NIC up with the old configuration - which, with
> dynamic IP addresses, could now include someone else's IP address! - is worse
> than useless.
You'll notice the pcmcia subsystem already
> Plese add power-saving devices like in notebooks to the list as well.
> For example in my notebook the PC speaker loops through the maestro-3e.
> The BIOS is initializing the maestro with some sane mixer values but
> after
> a suspend cycle the pc speaker is compleatly off due to suspension of
On Tue, 07 Nov 2000, Alan Cox wrote:
> > When I plug it in and modprobe is triggered to load the driver, a script then
> > runs to feed the device appropriate configuration info. Since the driver only
> > resets the hardware when it is given the correct configuration, there's no
> > problem.
>
>
> When I plug it in and modprobe is triggered to load the driver, a script then
> runs to feed the device appropriate configuration info. Since the driver only
> resets the hardware when it is given the correct configuration, there's no
> problem.
Thats another 100 lines of race prone network
Martin Mares wrote:
>
> Hi Alan!
>
> > If the sound card is only used some of the time or setup and then used
> > for TV its nice to get the 60K + 128K DMA buffer back when you dont need it
> > especially on a low end box
>
> So why don't we allocate / free the DMA buffer on device open /
Hello Horst!
> Strange somebody from a distribution forgets _the_ most important use of
> modules: Remember old-time Slackware, with dozens of different boot
> diskettes, and the imperative to compile a kernel to your machine once you
> got it running?
But how is this related to automatic
Alan Cox wrote:
>
> > It would probably be better (in this case) to increment the module count
> > when the mixer settings go above 0, and decrement it when the settings
> > go totally to 0. This prevents an unwanted unload.
>
> Thats about 200 lines of code and also about 50,000 emails
On Mon, 06 Nov 2000, Horst von Brand wrote:
> "James A. Sutherland" <[EMAIL PROTECTED]> said:
> > On Mon, 06 Nov 2000, Horst von Brand wrote:
>
> [...]
>
> > > The problem (AFAIU) is that if the levels aren't set on startup, they are
> > > random in some cases.
>
> > So set them on startup.
On Tue, 07 Nov 2000, Gerhard Mack wrote:
> > Then none of this is relevant to you, since you can't unload any modules! And
> > now you're the one doing the trolling... WTF do you think module code is
> > supposed to do when you don't use modules?!
> >
>
> Simple ... I'd rather the hardware was
On Tue, 07 Nov 2000, Gerhard Mack wrote:
Then none of this is relevant to you, since you can't unload any modules! And
now you're the one doing the trolling... WTF do you think module code is
supposed to do when you don't use modules?!
Simple ... I'd rather the hardware was set to 0
On Mon, 06 Nov 2000, Horst von Brand wrote:
"James A. Sutherland" [EMAIL PROTECTED] said:
On Mon, 06 Nov 2000, Horst von Brand wrote:
[...]
The problem (AFAIU) is that if the levels aren't set on startup, they are
random in some cases.
So set them on startup. NOT when the driver
Alan Cox wrote:
It would probably be better (in this case) to increment the module count
when the mixer settings go above 0, and decrement it when the settings
go totally to 0. This prevents an unwanted unload.
Thats about 200 lines of code and also about 50,000 emails complaining
Hello Horst!
Strange somebody from a distribution forgets _the_ most important use of
modules: Remember old-time Slackware, with dozens of different boot
diskettes, and the imperative to compile a kernel to your machine once you
got it running?
But how is this related to automatic unloading
Martin Mares wrote:
Hi Alan!
If the sound card is only used some of the time or setup and then used
for TV its nice to get the 60K + 128K DMA buffer back when you dont need it
especially on a low end box
So why don't we allocate / free the DMA buffer on device open / close instead
When I plug it in and modprobe is triggered to load the driver, a script then
runs to feed the device appropriate configuration info. Since the driver only
resets the hardware when it is given the correct configuration, there's no
problem.
Thats another 100 lines of race prone network kernel
On Tue, 07 Nov 2000, Alan Cox wrote:
When I plug it in and modprobe is triggered to load the driver, a script then
runs to feed the device appropriate configuration info. Since the driver only
resets the hardware when it is given the correct configuration, there's no
problem.
Thats
Plese add power-saving devices like in notebooks to the list as well.
For example in my notebook the PC speaker loops through the maestro-3e.
The BIOS is initializing the maestro with some sane mixer values but
after
a suspend cycle the pc speaker is compleatly off due to suspension of
the
In the NIC example, I might well want the DHCP client to run whenever I
activate the card. Bringing the NIC up with the old configuration - which, with
dynamic IP addresses, could now include someone else's IP address! - is worse
than useless.
You'll notice the pcmcia subsystem already
On Tue, 07 Nov 2000, Alan Cox wrote:
In the NIC example, I might well want the DHCP client to run whenever I
activate the card. Bringing the NIC up with the old configuration - which, with
dynamic IP addresses, could now include someone else's IP address! - is worse
than useless.
Alan Cox wrote:
In the NIC example, I might well want the DHCP client to run whenever I
activate the card. Bringing the NIC up with the old configuration - which, with
dynamic IP addresses, could now include someone else's IP address! - is worse
than useless.
You'll notice the pcmcia
eth0pegasus
nopersist eth0
post-install eth0 /usr/local/sbin/my-dhcp-stuff
So, in short, this is already done perfectly well in userspace without some
sort of Registry-style kernelside hack?
Thats the idea. Once the rmmod code can read back values the cycle is complete
and the
I've seen the same arguments over and over again here. It seems that there
are two feasible ways to accomplish persistence: totally kernel and
totally user-space
The totally kernel-space people want to make a way for modules to store
persistent data, either in memory, or across boots on
"James A. Sutherland" <[EMAIL PROTECTED]> said:
[...]
> That only happens if the driver is stupid enough to try guessing "correct"
> volume settings.
It did not touch anything: By a fluke, or by default, the sound output was
going full blast, and the mike input was patched over to it ==>
On Mon, 6 Nov 2000 23:00:05 + (GMT),
Paul Jakma <[EMAIL PROTECTED]> wrote:
>On Mon, 6 Nov 2000, Alan Cox wrote:
>> Its called modules.conf. It has all these nice preload directives in it
>
>cool..
>
>doesn't seem to be documented though in modutils 2.3.17. what exactly
>does it do?
man
On 06 Nov 2000 11:09:41 -0700,
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
>Well we don't have auto unload.
Check crontab, if it contains rmmod -a then you have auto unload.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Martin Mares <[EMAIL PROTECTED]> said:
[...]
> I think that automatic loading / unloading of modules has been a terrible hack
> since its first days (although back in these times a useful one) and that the
> era of its usefulness is over. There are zillions of problems with this
> mechanism,
Oliver Xymoron <[EMAIL PROTECTED]> say:
[...]
> Ioctl (or alternate device for plan9 groupies) is fine. My point is final
> initialization of the device is obviously delayed until the firmware is
> loaded.
Let's play perverse: What if I load the module, but don't initialize the
firmware, then
David Woodhouse <[EMAIL PROTECTED]> said:
[...]
> No. You should initialise the hardware completely when the driver is
> reloaded. Although the expected case is that the levels just happen to be
> the same as the last time the module was loaded, you can't know that the
> machine hasn't been
David Woodhouse <[EMAIL PROTECTED]> said:
> [EMAIL PROTECTED] said:
> > No funny "persistent data" mechanisms or screwups when the worker
> > gets removed and reinserted. In many cases the data module could be
> > shared among several others, in other cases it would have to be able
> > lo load
"James A. Sutherland" <[EMAIL PROTECTED]> said:
> On Mon, 06 Nov 2000, Horst von Brand wrote:
[...]
> > The problem (AFAIU) is that if the levels aren't set on startup, they are
> > random in some cases.
> So set them on startup. NOT when the driver is first loaded. Put it in
> the rc.d
> Then none of this is relevant to you, since you can't unload any modules! And
> now you're the one doing the trolling... WTF do you think module code is
> supposed to do when you don't use modules?!
>
Simple ... I'd rather the hardware was set to 0 on startup but I know what
problems that
On Tue, 07 Nov 2000, Gerhard Mack wrote:
> On Tue, 7 Nov 2000, James A. Sutherland wrote:
>
> > On Mon, 06 Nov 2000, Gerhard Mack wrote:
> > > Sure .. lets see you start a laptop in class or buisness meeting and have
> > > everyone turn to look at you wondering why your laptop let off an ear
> >
On Tue, 07 Nov 2000, Alan Cox wrote:
> > changing settings. If I plug in a hotplug soundcard and load the driver, I do
> > NOT want the driver to decide to set some settings. If I want settings set,
> > I'll do it myself (or have a script to do it).
>
> How about if your stuff is already nicely
On Tue, 7 Nov 2000, James A. Sutherland wrote:
> On Mon, 06 Nov 2000, Gerhard Mack wrote:
> > Sure .. lets see you start a laptop in class or buisness meeting and have
> > everyone turn to look at you wondering why your laptop let off an ear
> > piercing shreak because the hardware defaults to
On Mon, 06 Nov 2000, Gerhard Mack wrote:
> On Mon, 6 Nov 2000, James A. Sutherland wrote:
>
> > Except this isn't possible with the hardware in question! If it were, there
> > would be no problem. In cases where the hardware doesn't support the
> > functionality userspace "needs", why put the
> changing settings. If I plug in a hotplug soundcard and load the driver, I do
> NOT want the driver to decide to set some settings. If I want settings set,
> I'll do it myself (or have a script to do it).
How about if your stuff is already nicely set up and you remove then replug
a device, or
On Mon, 06 Nov 2000, Evan Jeffrey wrote:
> > On Mon, 06 Nov 2000, David Woodhouse wrote:
> > >
> > > No. You have to reset the hardware fully each time you load the module.
> > > Although you _expect_ it to be in the state in which you left it, you can't
> >
> > > be sure of that.
> >
> >
On Mon, 06 Nov 2000, Dan Hollis wrote:
> On Mon, 6 Nov 2000, James A. Sutherland wrote:
> > So autoload the module with a "dont_screw_with_mixer" option. When the kernel
> > first boots, initialise the mixer to suitable settings (load the module with
> > "do_screw_with_mixer" or whatever);
On Mon, 6 Nov 2000, James A. Sutherland wrote:
> Except this isn't possible with the hardware in question! If it were, there
> would be no problem. In cases where the hardware doesn't support the
> functionality userspace "needs", why put the kludge in the kernel?
>
> If userspace wants to know
On Mon, 6 Nov 2000, Alan Cox wrote:
> Its called modules.conf. It has all these nice preload directives in it
cool..
doesn't seem to be documented though in modutils 2.3.17. what exactly
does it do?
regards,
--
Paul Jakma [EMAIL PROTECTED]
PGP5 key:
IL PROTECTED] (Alan
Cox), [EMAIL PROTECTED] (Oliver Xymoron), [EMAIL PROTECTED] (Keith Owens),
[EMAIL PROTECTED] (bcc: Wayne Brown/Corporate/Altec)
Subject: Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 06 Nov 2000, Alan Cox wrote:
> > So a
> > if exists && is from this boot then && is right size
> > read data into __persistent ELF section
> > endif
>
> Alan, why are you stating "if it's from this boot"? I can think that
> maybe you want to keep stuff across boots too. Maybe once we're at it,
> have two
> Barring this, we could create a persistantdata module that we can
> modprobe and then discover with Keith's inter_module_xxx and read/write
> opaque data to/from. Then if the user does not want to use it they can
> just "alias persistantdata off" it and poof.
All of this is kernel code we
> the sound card case for persistent modules is contentious i think.
> what other good reasons are there for persistent data?
Maintaining TV tuning
Maintaining configuration options for USB
Maintaining radio tuner frequencies
Speeding up module reloading (avoiding expensive re-inits - eg 30
> i'd also like to see dist's adopt a nice config file specifying which
> modules to statically load at boot-time. (i know i want i them
> loaded). then maybe info from depmod could be applied to remove
> redundant loads.
Its called modules.conf. It has all these nice preload directives in it
>
> Some devices have a firmware.h that is compiled into the driver. A few
> sound devices use a function that loads a firmware file from userspace,
> given a filename. The comment in drivers/sound/sound_firmware.c says
> that this is a poor method, and that the recommended method for
> uploading
> It would probably be better (in this case) to increment the module count
> when the mixer settings go above 0, and decrement it when the settings
> go totally to 0. This prevents an unwanted unload.
Thats about 200 lines of code and also about 50,000 emails complaining people
cannot unload
Hi Alan!
> If the sound card is only used some of the time or setup and then used
> for TV its nice to get the 60K + 128K DMA buffer back when you dont need it
> especially on a low end box
So why don't we allocate / free the DMA buffer on device open / close instead
of module insert / remove?
> On Mon, 06 Nov 2000, David Woodhouse wrote:
> >
> > No. You have to reset the hardware fully each time you load the module.
> > Although you _expect_ it to be in the state in which you left it, you can't
>
> > be sure of that.
>
> If a reset is needed, I think it should come explicitly
Alan Cox wrote:
> A simple more generic solution is to do this
[]
> if exists && is from this boot then && is right size
> read data into __persistent ELF section
> endif
Alan, why are you stating "if it's from this boot"? I can think that
maybe you want to keep
Could we handle this by setting a nomixerreset=1 option in modules.conf
or as the module default that would effect module reloads. Then on boot
up explicitly modprobe with a mixerlevel=0 and then set the levels via
aumix etc?
This way the existing hardware can keep the levels if it knows how. As
David Woodhouse <[EMAIL PROTECTED]> writes:
> The current situation is equivalent to stopping forwarding packets each
> time an app on the local machine decides it wants to send its own packets,
> after a period of inactivity.
>
> Defaulting to zero on boot is fine. Defaulting to zero after the
On Mon, 6 Nov 2000, Jeff Garzik wrote:
> Oliver Xymoron wrote:
> >
> > On Mon, 6 Nov 2000, David Woodhouse wrote:
> >
> > > The point here is that although I've put up with just keeping the sound
> > > driver loaded for the last few years, permanently taking up a large amount
> > > of DMA
On Mon, 6 Nov 2000, James A. Sutherland wrote:
> So autoload the module with a "dont_screw_with_mixer" option. When the kernel
> first boots, initialise the mixer to suitable settings (load the module with
> "do_screw_with_mixer" or whatever); thereafter, the driver shouldn't change
> the mixer
On Mon, 6 Nov 2000, Alan Cox wrote:
> Which is part of what persistent module data lets you do. And without having
> to mess with dont_screw_with_mixer (which if you get it wrong btw can be
> fatal and hang the hardware)
>
the sound card case for persistent modules is contentious i think.
Oliver Xymoron wrote:
>
> On Mon, 6 Nov 2000, David Woodhouse wrote:
>
> > The point here is that although I've put up with just keeping the sound
> > driver loaded for the last few years, permanently taking up a large amount
> > of DMA memory, the inter_module_xxx stuff that Keith is proposing
On Mon, 6 Nov 2000, David Woodhouse wrote:
> No. You should initialise the hardware completely when the driver is
> reloaded.
and it is. just that 'mixer levels' are subjective - different users
have different tastes. in what way does:
- init to mute
- user set to liking
fail people?
On Mon, 6 Nov 2000, Alan Cox wrote:
> If the sound card is only used some of the time or setup and then used
> for TV its nice to get the 60K + 128K DMA buffer back when you dont need it
> especially on a low end box
>
so unload it then - aiui most soundcards will continue passing through
the
On Mon, 6 Nov 2000, David Woodhouse wrote:
> The point here is that although I've put up with just keeping the sound
> driver loaded for the last few years, permanently taking up a large amount
> of DMA memory, the inter_module_xxx stuff that Keith is proposing would
> give us a simple way of
On Mon, 6 Nov 2000, David Woodhouse wrote:
> * Sound module is autoloaded again, default to zero levels.
so you use the 'post-install' option of modules.conf to run your
mixer-level setting script.
> This time it is _NOT_ fine. User is rightly pissed off :)
>
even better: is there any
On Mon, 06 Nov 2000, David Woodhouse wrote:
> [EMAIL PROTECTED] said:
> > Except this isn't possible with the hardware in question! If it were,
> > there would be no problem. In cases where the hardware doesn't support
> > the functionality userspace "needs", why put the kludge in the kernel?
>
On Mon, 06 Nov 2000, David Woodhouse wrote:
> [EMAIL PROTECTED] said:
> > So set them on startup. NOT when the driver is first loaded. Put it
> > in the rc.d scripts.
>
> No. You should initialise the hardware completely when the driver is
> reloaded. Although the expected case is that the
[EMAIL PROTECTED] said:
> Except this isn't possible with the hardware in question! If it were,
> there would be no problem. In cases where the hardware doesn't support
> the functionality userspace "needs", why put the kludge in the kernel?
> If userspace wants to know what settings it set
On Mon, 06 Nov 2000, Alan Cox wrote:
> > So autoload the module with a "dont_screw_with_mixer" option. When the kernel
> > first boots, initialise the mixer to suitable settings (load the module with
> > "do_screw_with_mixer" or whatever); thereafter, the driver shouldn't change
> > the mixer
On Mon, 06 Nov 2000, David Woodhouse wrote:
> [EMAIL PROTECTED] said:
> > Yippee. As we all know, implementing GUI volume controls and putting
> > the slider in the right place is a kernel function, and nothing to do
> > with userspace...
>
> Don't troll, James. The kernel needs to provide the
[EMAIL PROTECTED] said:
> > No! The best way to do it are just *persistently loaded* modules.
> > It's THAT simple!
>
So you want to split every sound driver into two or more modules ?
The point here is that although I've put up with just keeping the sound
driver loaded for the last few
> 1. Before auto-unload of the driver, run a small utility which will read
> mixer settings
>and save them somewhere
> 2. When auto-loading the driver, use driver arguments which are initialized
> from the
>settings saved above
> All that's missing is the method of passing data from step
> Not quite: plugging physically hardware in and out is compleatly
> different
> then just loading a driver and unconditionally unloading it even when
> the hardware is still there!
Actually its no different.
Suppose I unplug my USB speakers and plug them back in again (perhaps Im just
adding a
> Drivers are supposed to handle present hardware - if the hardware
> is there - there should be a driver handling it as well.
Thats not how things have worked historically. Thats not consistent with other
modules either.
> The argument for saving some memmory is nonapplicable becouse in
> the
[EMAIL PROTECTED] said:
> The best solution to the sound driver issue, IMHO, is still entirely
> userspace--- just no-one has written it yet. What we should do: 1.
> Before auto-unload of the driver, run a small utility which will read
> mixer settings
>and save them somewhere 2. When
OTECTED]>
Sent: Monday, November 06, 2000 19:06
Subject: Re: Persistent module storage [was Linux 2.4 Status / TODO page]
>
> [EMAIL PROTECTED] said:
> > No funny "persistent data" mechanisms or screwups when the worker
> > gets removed and reinserted. In many cases
> No funny "persistent data" mechanisms or screwups when the worker gets
> removed and reinserted. In many cases the data module could be shared among
> several others, in other cases it would have to be able lo load several
> times or manage several incarnations of its payload.
It actually
> > Persistent storage is the best way to do it though. It doesn't have to be
> > persistent over reboots, just during the lifetime of the kernel.
>
> No! The best way to do it are just *persistently loaded* modules.
> It's THAT simple!
So you want to split every sound driver into two or more
Alan Cox wrote:
>
> > >Just load the driver at bootup and forget about it. Problem solved.
> >
> > I daily curse the name of whoever added autoload and autounload.
> > Autoload maybe useful, autounload is just asking for problems.
>
> Deal with it. Hardware is also now auto load and auto
> So autoload the module with a "dont_screw_with_mixer" option. When the kernel
> first boots, initialise the mixer to suitable settings (load the module with
> "do_screw_with_mixer" or whatever); thereafter, the driver shouldn't change
> the mixer settings on load.
Which is part of what
[EMAIL PROTECTED] said:
> So set them on startup. NOT when the driver is first loaded. Put it
> in the rc.d scripts.
No. You should initialise the hardware completely when the driver is
reloaded. Although the expected case is that the levels just happen to be
the same as the last time the
On Mon, 06 Nov 2000, Horst von Brand wrote:
> [Chopped down Cc: list]
> "James A. Sutherland" <[EMAIL PROTECTED]> said:
> > On Mon, 06 Nov 2000, David Woodhouse wrote:
>
> [...]
>
> > > It does not know them. Correct. But with persistent module storage, it
> > > _could_ know them.
>
> > No it
[Chopped down Cc: list]
"James A. Sutherland" <[EMAIL PROTECTED]> said:
> On Mon, 06 Nov 2000, David Woodhouse wrote:
[...]
> > It does not know them. Correct. But with persistent module storage, it
> > _could_ know them.
> No it cannot. The desired levels have not been defined: there are no
On Mon, 06 Nov 2000, David Woodhouse wrote:
> [EMAIL PROTECTED] said:
> > Irrelevant. The current mixer settings don't matter: what matters is
> > that the driver does not change them.
>
> It does matter. The sound driver needs to be able to _read_ the current
> levels.
So do so. That's a
David Woodhouse <[EMAIL PROTECTED]> said:
> [EMAIL PROTECTED] said:
> > Irrelevant. The current mixer settings don't matter: what matters is
> > that the driver does not change them.
> It does matter. The sound driver needs to be able to _read_ the current
> levels. Almost all mixer programs
[EMAIL PROTECTED] said:
> Irrelevant. The current mixer settings don't matter: what matters is
> that the driver does not change them.
It does matter. The sound driver needs to be able to _read_ the current
levels. Almost all mixer programs will start by doing this, to set the
slider to the
On Mon, 06 Nov 2000, David Woodhouse wrote:
> [EMAIL PROTECTED] said:
> > So autoload the module with a "dont_screw_with_mixer" option. When
> > the kernel first boots, initialise the mixer to suitable settings
> > (load the module with "do_screw_with_mixer" or whatever); thereafter,
> > the
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > * Driver initializes mixer to 100% muted * Userspace app sets desired
> > values to /dev/mixer * Userspace app opens /dev/dsp to play sound
>
> > I don't see where any sound can "escape" in this scenario, and it
> > doesn't require any
[EMAIL PROTECTED] said:
> I am thinking about the bigger picture: You are unloading a driver,
> then continuing to use the hardware. To me, that is an undefined
> state.
We're only using the pass-through levels. It's undefined but it doesn't
matter to the software. I'd actually suggest that
On Mon, Nov 06, 2000 at 08:00:05AM +, David Woodhouse wrote:
> I'm more interested in the case where the module is loaded for the second
> time:
Is there really a reason to unload a module in normal usage? Beyond
miniscule memory savings and hack value? You can solve the whole
problem with
[EMAIL PROTECTED] said:
> So autoload the module with a "dont_screw_with_mixer" option. When
> the kernel first boots, initialise the mixer to suitable settings
> (load the module with "do_screw_with_mixer" or whatever); thereafter,
> the driver shouldn't change the mixer settings on load.
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > > The sound card allows itself to be unloaded when the pass-through
> > > mixer levels are non-zero. This is reasonable iff ...
>
> > I don't think that is reasonable.
>
> You don't think that it's reasonable for the sound card to allow
On Mon, 06 Nov 2000, David Woodhouse wrote:
> [EMAIL PROTECTED] said:
> > > * User continues to happily listen to radio through sound card
> > You're using the sound card without a driver?
>
> Yes. The sound card allows itself to be unloaded when the pass-through mixer
> levels are non-zero.
I think we're getting confused. What I'm advocating is something like this:
init_module()
{
struct mixer_levels *levels;
levels = inter_module_get("mysoundcard_mixerlevels");
if (!levels)
/* We haven't been loaded before. Default to zero */
[EMAIL PROTECTED] said:
> > The sound card allows itself to be unloaded when the pass-through
> > mixer levels are non-zero. This is reasonable iff ...
> I don't think that is reasonable.
You don't think that it's reasonable for the sound card to allow itself to
be unloaded when the
On Mon, 06 Nov 2000 07:13:07 -0500,
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>...or, give up this silly nonsense about loading and unload modules on
>every open() and close(). A module load modifies the running kernel
>code... why do people do this on such a whim?
>
>Just load the driver at
> I don't think that is reasonable.
I think its totally reasonable.
> The first thing most drivers do is reset the hardware. That inevitably
Because there is no persistent storage to remember the fact the hardware is
running.
> You are depending on the hardware to keep its state -between-
David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > > * User continues to happily listen to radio through sound card
> > You're using the sound card without a driver?
>
> Yes. The sound card allows itself to be unloaded when the pass-through mixer
> levels are non-zero. This is reasonable
[EMAIL PROTECTED] said:
> > * User continues to happily listen to radio through sound card
> You're using the sound card without a driver?
Yes. The sound card allows itself to be unloaded when the pass-through mixer
levels are non-zero. This is reasonable iff it can be reloaded without
David Woodhouse wrote:
> * Sound module is unloaded
> * User continues to happily listen to radio through sound card
You're using the sound card without a driver?
> * Time passes
> * User is listening intently to something on the radio
> * Something wants to beep through /dev/audio
> * Sound
1 - 100 of 193 matches
Mail list logo
