> > > 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/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:27 EST