lkml.org 
[lkml]   [2002]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] Raceless module interface
Date
In message <E17pLKe-0007ds-00@starship> you write:
> As I recall, you are the one who proposed eliminating the ability
> to unload modules entirely, because you were not able to solve the
> unload races.

Huh? I was able to solve the module races, in multiple ways. I even
had an implementation, using two stage init and two stage remove. But
it's not *simple*, and pushing additional constraints on kernel driver
authors may be worse than not being able to remove modules.

> It's a good thing that people with more sense shouted you down.

There was (understandably) some resistance to removing a "working"
feature, but noone produced a new workable alternative.

The *point* of my presentation was to make people think of
alternatives, especially, if we can't (or don't want to) solve all the
unload races, is it OK to say "well, you can't unload those kind of
modules"?

If I had come up with a clear winner, I might have saved myself the
pain of standing up in front of 70 of my peers and admitting that I
wasn't smart enough, ferchissakes.

But it doesn't help if you don't listen, then sprout the "one true
solution" which turns out to be a wordy combination two previously
discussed schemes, with the disadvantages of both.

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:28    [W:0.161 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site