lkml.org 
[lkml]   [2003]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Remove module reference counting.
Date
In message <20030725122651.4aedc768.shemminger@osdl.org> you write:
> On Fri, 25 Jul 2003 04:00:18 +1000
> Rusty Russell <rusty@rustcorp.com.au> 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.
> >
> > Polite feedback welcome,
> > Rusty.
> > --
>
> There are two possible objections to this:
> * Some developers keep the same kernel running and load/unload then reload
> a new driver when debugging. This would break probably or at least cause
> a large amount of kernel growth. Not that big an issue for me personally
> but driver writers seem to get hit with all the changes.

No, it would just leak memory. Not really a concern for developers.
It's fairly trivial to hack up a backdoor "remove all freed modules
and be damned" thing for developers if there's real demand.

> * Drivers might get sloppy about not cleaning up timers and data
> structures -- more than they are already. You might want to have a
> kernel debug option that overwrite's the unloaded text with
> something guaranteed to cause an oops.

I already have a poisoning patch for init code, when some modules
seemed to suffer from this being discarded. I can extend it.

Thanks!
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/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.094 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site