From: Martin Dalecki <dalecki@evision-ventures.com>
To: Martin Mares <mj@suse.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Vojtech Pavlik <vojtech@suse.cz>,
Jeff Garzik <jgarzik@mandrakesoft.com>,
David Woodhouse <dwmw2@infradead.org>,
Dan Hollis <goemon@anime.net>,
Oliver Xymoron <oxymoron@waste.org>,
Keith Owens <kaos@ocs.com.au>,
linux-kernel@vger.kernel.org
Subject: Re: Persistent module storage [was Linux 2.4 Status / TODO page]
Date: Tue, 07 Nov 2000 11:59:17 +0100 [thread overview]
Message-ID: <3A07E085.3661EB6D@evision-ventures.com> (raw)
In-Reply-To: <3A06A053.56F09ACB@mandrakesoft.com> <E13sphu-0006O4-00@the-village.bc.nu> <20001106221254.A1196@albireo.ucw.cz>
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
> of module insert / remove? If the reason lies in problems with allocation
> of large chunks of contiguous memory, we're going to have exactly the same
> problems when autoloading the module.
>
> 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, the most important ones being:
Amen.
> o It would have to preserve _complete_ device state over module reload.
> For the sound card mixer settings discussed it's close to trivial, but
> for example consider a tape drive and the problem of preserving tape
> position after reload (probably including device reset causing tape rewind).
> And what about textures loaded to memory of a 3D video card?
>
> o For many drivers, the "device currently open" concept makes no sense.
> Consider a mouse driver whose only activity is to feed mouse events
> to an event device. The mouse driver can be unloaded in any time (either
> manually or perhaps automatically after the mouse gets unplugged), hence
> it should have a use count == zero, but even if it seems to be unused,
> it must not be unloaded just because of some timeout since the mouse
> will cease to work.
>
> o It interferes with hotplug in nasty ways. Let's have a USB host controller
> driver with currently no devices on its bus. It's also an example of a zero
> use count driver, but it also must not be unloaded as it's needed for
> recognizing newly plugged in devices.
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
maestro-3e chip and the leak of a *permanent* driver sitting around to
handle
the wakeup event.
> I don't argue whether we need or need not some kind of persistent storage for
> the modules (it might be a good idea when it comes to hotplug, but it should
> be probably taken care of by the userspace hotplug helpers), but I think that
> it has no chance to solve the problems with automatic unloading.
>
> We could of course attempt to circumvent the problems listed above by adding
> some hints to module state which will say whether it's possible to auto-unload
> the module or not even if it has zero use count, but it means another thing
> to handle in all the drivers (well, at least another thing to think of whether
> it's needed or not for each driver) and I think that the total effect of
> the autounloading mechanism (a minimum amount of memory saved) in no way
> outweighs the cost of implementing it right.
And the pain for the user of the whole: Take the example of ALSA
over-modularisation...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-07 10:07 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3A06A053.56F09ACB@mandrakesoft.com>
2000-11-06 12:29 ` Persistent module storage [was Linux 2.4 Status / TODO page] Keith Owens
2000-11-06 17:07 ` Alan Cox
2000-11-06 18:09 ` Martin Dalecki
2000-11-06 17:30 ` Alan Cox
2000-11-06 17:05 ` Alan Cox
2000-11-06 18:30 ` Paul Jakma
2000-11-06 21:12 ` Martin Mares
2000-11-07 1:17 ` Horst von Brand
2000-11-07 9:59 ` Martin Mares
2000-11-07 10:59 ` Martin Dalecki [this message]
2000-11-07 12:27 ` Alan Cox
2000-11-07 7:55 David Feuer
-- strict thread matches above, loose matches on Subject: below --
2000-11-06 22:48 Wayne.Brown
2000-11-06 0:54 Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10) David Woodhouse
2000-11-06 1:28 ` Persistent module storage [was Linux 2.4 Status / TODO page] Keith Owens
2000-11-06 6:39 ` David Woodhouse
2000-11-06 7:12 ` Oliver Xymoron
2000-11-06 7:17 ` David Woodhouse
2000-11-06 7:25 ` Jeff Garzik
2000-11-06 7:29 ` David Woodhouse
2000-11-06 10:53 ` Alan Cox
2000-11-06 11:03 ` Dan Hollis
2000-11-06 11:04 ` Jeff Garzik
2000-11-06 11:35 ` Alan Cox
2000-11-06 11:36 ` Jeff Garzik
2000-11-06 11:06 ` David Woodhouse
2000-11-06 11:09 ` Jeff Garzik
2000-11-06 11:20 ` Jeff Garzik
2000-11-06 11:37 ` David Woodhouse
2000-11-06 11:40 ` Jeff Garzik
2000-11-06 11:47 ` David Woodhouse
2000-11-06 11:57 ` Jeff Garzik
2000-11-06 12:03 ` Alan Cox
2000-11-06 13:12 ` David Woodhouse
2000-11-06 13:38 ` Jeff Garzik
2000-11-06 13:56 ` David Woodhouse
2000-11-06 13:21 ` David Woodhouse
2000-11-06 13:35 ` James A. Sutherland
2000-11-06 17:12 ` Alan Cox
2000-11-06 17:38 ` James A. Sutherland
2000-11-06 18:39 ` Paul Jakma
2000-11-06 21:28 ` Alan Cox
2000-11-06 18:55 ` Dan Hollis
2000-11-07 0:18 ` James A. Sutherland
2000-11-07 0:27 ` Alan Cox
2000-11-07 0:38 ` James A. Sutherland
2000-11-07 12:07 ` Alan Cox
2000-11-07 12:13 ` James A. Sutherland
2000-11-07 12:35 ` Alan Cox
2000-11-07 12:49 ` James A. Sutherland
2000-11-07 12:52 ` Alan Cox
2000-11-07 12:51 ` Petko Manolov
2000-11-06 13:40 ` David Woodhouse
2000-11-06 15:23 ` James A. Sutherland
2000-11-06 15:34 ` David Woodhouse
2000-11-06 16:31 ` Horst von Brand
2000-11-06 17:06 ` David Woodhouse
2000-11-06 17:25 ` Alon Ziv
2000-11-06 17:34 ` Alan Cox
2000-11-06 19:49 ` Rogier Wolff
2000-11-06 21:34 ` Alan Cox
2000-11-06 17:25 ` David Woodhouse
2000-11-06 19:27 ` Tim Riker
2000-11-06 21:33 ` Alan Cox
2000-11-06 23:57 ` Horst von Brand
2000-11-06 17:23 ` Alan Cox
2000-11-08 14:56 ` Jamie Lokier
2000-11-06 18:00 ` Martin Dalecki
2000-11-06 17:29 ` Alan Cox
2000-11-06 16:42 ` James A. Sutherland
2000-11-06 16:57 ` Horst von Brand
2000-11-06 17:01 ` James A. Sutherland
2000-11-06 23:54 ` Horst von Brand
2000-11-07 8:44 ` James A. Sutherland
2000-11-06 17:12 ` David Woodhouse
2000-11-06 17:45 ` James A. Sutherland
2000-11-06 18:37 ` Paul Jakma
2000-11-07 0:04 ` Horst von Brand
2000-11-06 17:08 ` David Woodhouse
2000-11-06 17:33 ` James A. Sutherland
2000-11-06 23:28 ` Gerhard Mack
2000-11-07 0:34 ` James A. Sutherland
2000-11-07 0:42 ` Gerhard Mack
2000-11-07 0:43 ` James A. Sutherland
2000-11-07 1:20 ` Gerhard Mack
2000-11-07 8:41 ` James A. Sutherland
2000-11-07 1:44 ` Horst von Brand
2000-11-06 17:44 ` David Woodhouse
2000-11-06 17:53 ` James A. Sutherland
2000-11-06 20:46 ` Evan Jeffrey
2000-11-07 0:23 ` James A. Sutherland
2000-11-06 15:15 ` Martin Dalecki
2000-11-06 17:19 ` Alan Cox
2000-11-06 17:34 ` David Woodhouse
2000-11-06 18:22 ` Oliver Xymoron
2000-11-06 18:37 ` Jeff Garzik
2000-11-06 19:09 ` Oliver Xymoron
2000-11-07 0:32 ` Horst von Brand
2000-11-06 21:19 ` Alan Cox
2000-11-06 18:22 ` Paul Jakma
2000-11-06 21:18 ` Alan Cox
2000-11-06 23:00 ` Paul Jakma
2000-11-07 2:11 ` Keith Owens
2000-11-06 7:28 ` Oliver Xymoron
2000-11-06 7:32 ` David Woodhouse
2000-11-06 7:45 ` Jeff Garzik
2000-11-06 8:00 ` David Woodhouse
2000-11-06 13:44 ` Andrew Pimlott
2000-11-06 7:48 ` Oliver Xymoron
2000-11-06 8:02 ` David Woodhouse
2000-11-06 18:09 ` Eric W. Biederman
2000-11-06 21:17 ` Alan Cox
2000-11-07 9:55 ` Helge Hafting
2000-11-07 2:09 ` Keith Owens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A07E085.3661EB6D@evision-ventures.com \
--to=dalecki@evision-ventures.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dwmw2@infradead.org \
--cc=goemon@anime.net \
--cc=jgarzik@mandrakesoft.com \
--cc=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=mj@suse.cz \
--cc=oxymoron@waste.org \
--cc=vojtech@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).