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

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

    \
     
     \ /
      Last update: 2005-03-22 13:22    [W:0.040 / U:0.168 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site