[lkml]   [2002]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Raceless module interface

On Fri, 13 Sep 2002, Daniel Phillips wrote:
> On Friday 13 September 2002 16:33, Thunder from the hill wrote:
> > Look, first we watch the module initialization, that is, we run the
> > critical stuff like resource allocation, data structure allocation, etc.
> > If we fail here, we can't load the module, because it would be unoperative
> > if we proceed. (Because the data simply isn't there.)

-> if we don't do the starting here, we can operate on the data structures
earlier, since we know they're running free.

Also could we run start again, even though it sounds buggy.

> > And possibly Rusty wanted to avoid a certain race, which is unrelated to
> > school and kids.

Ouch. I've referred to a comparison here which I've dropped lateron. Sorry
if you felt insulted.

> please identify the race Rusty avoided and show how I did not avoid the
> same race.

I'm sure Rusty could do that better. However, there might be some weird
situations. For example, take someone trying to bring all modules down
the moment we init. We might start running in unchecked environment, and
there we fail because there is no 'we' any more.

Thus rather module->init(). if (module) module->start(). Since then we can
be sure that the module is locked, and if somebody unloads it, he'll have
to wait for the use count to drop.

Or as another example, take someone trying to use the resources we claimed
before the module is really up. If you can rely on the module to be known
to be up, you know what do do. Yes, usually that's no real good example,
since resources ought to be locked as well.

--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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