[lkml]   [2002]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Raceless module interface
On Friday 13 September 2002 16:59, Thunder from the hill wrote:
> Hi,
> 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.

We can do this without having start separte from init as well.

> > please identify the race Rusty avoided and show how I did not avoid the
> > same race.
> I'm sure Rusty could do that better.

I'd be surprised if Rusty can do it any better than you. It's hard to
show a race that doesn't exist, even harder to prove that a four-prong
interface is necessary in order to be able to handle it. The latter is
the question on the table.

> 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.

Oh indeed, there are weird situations, but they apply equally to the
two-prong and the four-prong interfaces.

> 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.

This applies equally to the two-prong interface.

> 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.

This applies equally to the two-prong interface. Do you see the pattern

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.103 / U:1.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site