Messages in this thread |  | | From | Daniel Phillips <> | Subject | Re: [RFC] Raceless module interface | Date | Fri, 13 Sep 2002 17:17:07 +0200 |
| |
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 yet?
-- Daniel - 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/
|  |