Messages in this thread |  | | From | Oliver Neukum <> | Subject | Re: [RFC] Raceless module interface | Date | Wed, 11 Sep 2002 22:29:11 +0200 |
| |
> > > magic_wait_for_quiescence to complete. So the try_count approach is > > > preferable, where it works. > > > > But the try_count approach hurts every user of the defined interfaces, > > even if modules are not used. > > Well, it works great for filesystems, which is my point. And I'll > bet beer that somebody out there will find another application > where it works well. It's all about choice, and the thing about
How would the other version work less well for filesystems ? How long unloading takes doesn't matter, as long as it's safe. The overhead while running is the issue, nothing else.
> the proposed interface is, it gives you the flexibility to make > that choice. The fact that it's also the simplest interface is > just nice.
That makes no difference if you have to support two interfaces.
> > Is the impact on the scheduler limited > > to the time magic_wait_for_quiescence is running. > > If so, the approach looks superior. > > It definitely is not superior for filesystem modules. However, > "damm good" would be a nice level of functionality to aim for. > The more we come to rely on virtual filesystem, the more we care > that the load/unload procedure should be reliable and fast.
What? Unloading is a rare event in any case.
> Don't forget that point about not being able to put an upper > bound on the time required to complete the magic wait. > > Are you hinting that we only need, and only ever will need, one > mechanism here, so the module doesn't need to return a result > from cleanup_module? If so then I should add that we don't just
Returning the error value is good.
> have varying requirements for cleanup style between modules, but > other problems, such as single modules that support multiple > services, which are common in the pcmcia world.
Regards Oliver
- 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/
|  |