Re: [RFC] Raceless module interface

[Daniel Phillips <phillips@arcor.de>]

On Wednesday 11 September 2002 20:53, Oliver Neukum wrote:
> > Now there's the question "if this is such a great approach, why not make
> > all modules work this way, not just filesystems?".  Easy: the magic
> > scheduling approach impacts the scheduler, however lightly, and worse,
> > we cannot put an upper bound on the time needed for
> 
> You are in principle describing RCU. These guys seem to have solved the
> problem.

Eh, how about that, and it was obvious to me.  I wonder what that 
means, if anything.  (No, I never knew anything about RCU other
than the name.)  Anyway, in case I sound too snippy here, here's
a hearty thanks to IBM for contributing that IP to Linux without
a fuss.

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

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

-- 
Daniel