[lkml]   [2002]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Raceless module interface

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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.129 / U:4.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site