Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: [RFC] Raceless module interface | Date | Fri, 13 Sep 2002 04:19:18 +0200 |
| |
On Friday 13 September 2002 03:30, Rusty Russell wrote: > In message <Pine.LNX.4.44.0209121520300.28515-100000@serv> you write: > > The usecount is optional, the only important question a module must be > > able to answer is: Are there any objects/references belonging to the > > module? It's a simple yes/no question. If a module can't answer that, it > > likely has more problem than just module unloading. > > Ah, we're assuming you insert synchronize_kernel() between the call > to stop and the call to exit? > > In which case *why* do you check the use count *inside* exit_affs_fs? > Why not get exit_module() to do "if (mod->usecount() != 0) return > -EBUSY; else mod->exit();"?
Because mod->usecount may be a totally inadequate way of determining if a module is busy. How does it work for LSM, for example?
> There's the other issue of symmetry. If you allocate memory, in > start, do you clean it up in stop or exit?
Actually, I'm going to press you on why you think you even need a two stage stop. I know you have your reasons, but I doubt any of the effects you aim at cannot be achieved with a single stage stop/exit. Could you please summarize the argument in favor of the two stage stop?
> Similarly for other > resources: you call mod->exit() every time start fails, so that is > supposed to check that mod->start() succeeded?
He does? That's not right. ->start should clean up after itself if it fails, like any other good Linux citizen.
> Of course, separating start into "init" and "start" allows you to > solve the half-initialized problem as well as clarify the rules.
I doubt it gives any new capability at all. The same with the entrenched separation at the user level between create and init module: what does it give you that an error exit from a single create/init would not? Sure, I know it's not going to change, but I'd like to know what the thinking was, and especially, if there's a non-bogus reason, I'd like to know it.
-- 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/
| |