In message <1059175489.1206.11.camel@dhcp22.swansea.linux.org.uk> you write:
> On Gwe, 2003-07-25 at 20:26, Stephen Hemminger wrote:
> > > If module removal is to be a rare and unusual event, it
> > > doesn't seem so sensible to go to great lengths in the code to handle
> > > just that case. In fact, it's easier to leave the module memory in
> > > place, and not have the concept of parts of the kernel text (and some
> > > types of kernel data) vanishing.
>
> Uggh. There is a difference between taking the approach that some stuff
> is hard to handle and gets into trouble for using MOD_INC/DEC so is
> unsafe, and doing the locking from the caller, or arranging that you
> know the device is quiescent in the unload path and not allowing
> unloading to work properly.
We can do this everywhere: we have the technology. But as I pointed
out, at least some hackers who know what they are doing have balked at
what that involves. This is apart from the subsystems which are still
not safe as it stands.
> I've got drivers that use MOD_INC/DEC and are technically unsafe, they
> by default now don't unload and its an incentive to fix them. I'd hate
> to have my box cluttering up and have to keep rebooting to test drivers
> because of inept implementations however.
But OTOH, this patch would make those modules perfectly safe: no
fixing needed.
One modification is to tally up the deleted modules in /proc/modules
under a "[deleted]" entry or somesuch, but allow you to "rmmod
[deleted]" and actually free that memory (and taint your kernel). eg:
# lsmod
Module Size Used by
loop 8144 0
[deleted] 12345
# rmmod '[deleted]'
Thoughts?
Rusty.
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - 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/
This archive was generated by hypermail 2b29 : Thu Jul 31 2003 - 22:00:34 EST