From: Peter Williams <peterw@aurema.com>
To: Grzegorz Kulewski <kangur@polcom.net>
Cc: Marek Szuba <scriptkiddie@wp.pl>, linux-kernel@vger.kernel.org
Subject: Re: 2.6.4, or what I still don't quite like about the new stable branch
Date: Tue, 16 Mar 2004 11:17:39 +1100 [thread overview]
Message-ID: <405647A3.4030202@aurema.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0403131932510.22707@alpha.polcom.net>
Grzegorz Kulewski wrote:
>>4. Module autounloading. Is it actually possible? Will it be possible?
>>If not, why? The old method of periodically invoking "modprobe -ras" via
>>cron doesn't seem to accomplish anything and I really liked the idea of
>>keeping only the required modules in memory at any given moment without
>>having to log in as root to unload the unneeded ones - after all, if the
>>autoloader can only add them what's the point of not going the
>>monolithic way? The docs on the new approach towards modules are
>>virtually nonexistent in the kernel source package and while I suppose I
>>could simply write a script which would scan the list of
>>currently-loaded modules for the unused ones and remove them one by one,
>>but this approach feels terribly crude comparing with the elegance of
>>the old solution. I use module-init-tools-3.0, a serious improvement
>>over 0.9.15 if I may say so but, unless I'm thinking about it with
>>completely wrong base assumptions, still far from perfect.
>
>
> As far as I know, the new preffered way of handling modules, is to load
> them when device is detected (hotplug and udev, at boot or later)
> and (optionally) remove when device is removed, not as in older kernels,
> when module was added or removed depending on its use. This way (as
> opposed to monolithic kernel) you can have "generic" kernel by placing
> everything in modules. And what is the point in unloading not currently
> needed modules?
It enables you to update a module (e.g. to fix a bug) without having to
do a reboot. I think that people trying to use Linux for useful work
would find this useful. So unloadable modules is certainly a
functionality worth aiming for.
> They should not use much resources when not needed...
> And if you want to put your system to sleep, you must put to sleep all
> devices (in the right order) *including* these not currently used but
> present in the system. If you will not do this, you can probably get big
> crash. So you need loaded module, that knows how to put device to sleep.
>
>
> Grzegorz Kulewski
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Dr Peter Williams, Chief Scientist peterw@aurema.com
Aurema Pty Limited Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com
next prev parent reply other threads:[~2004-03-16 0:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-13 18:27 2.6.4, or what I still don't quite like about the new stable branch Marek Szuba
2004-03-13 18:44 ` Grzegorz Kulewski
2004-03-16 0:17 ` Peter Williams [this message]
2004-03-13 21:54 ` Alex Goddard
[not found] ` <4058097F.4070606@aitel.hist.no>
2004-03-17 22:27 ` Alex Goddard
2004-03-17 22:40 ` Stephen Hemminger
2004-03-13 22:21 ` Sam Ravnborg
2004-03-17 23:15 ` James Simmons
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=405647A3.4030202@aurema.com \
--to=peterw@aurema.com \
--cc=kangur@polcom.net \
--cc=linux-kernel@vger.kernel.org \
--cc=scriptkiddie@wp.pl \
/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