lkml.org 
[lkml]   [2010]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
    On Wed, 2 Jun 2010 21:02:24 +1000
    Neil Brown <neilb@suse.de> wrote:
    >
    > And this decision (to block suspend) really needs to be made in the driver,
    > not in userspace?

    Well, it fits. The requirement is a direct consequence of the intimate
    knowledge the driver has about the driven devices.
    Or if you get in an upper layer, the knowledge that the subsystem has
    about it's requirements to function properly. Why would you separate it out?

    If all your drivers specify their needed requirements, the pm-core (or
    idle) has the maximum flexibility to implement any strategy and is
    guaranteed a stable system as long as it honours the given requirements.
    (That's the theory, of course.)

    >
    > You could get those drivers to return EBUSY from PM_SUSPEND_PREPARE (which
    > would need to be a configurable option), but then I guess you have no way to
    > wait for the device to become non-busy.
    >
    > If user-space really cannot tell if the driver is busy or not, then I would
    > suggest that the driver is fairly poorly designed.

    In general, userspace has no business knowing if the driver is busy or
    not. It would need intimate knowledge about the driver to determine if
    it is busy or not. That is what the kernel is all about, to hide that
    knowledge from userspace and masking it with a one-fits-all-API.


    >
    > It would seem then that a user-space requested suspend is not sufficient for
    > your needs even if we remove the race window, as you have drivers that want
    > to avoid suspend indefinitely, and that "need to avoid suspend" status is not
    > visible from user-space.

    Well, but the kernel-solution and the userspace solution should be
    pretty independent. The tricky part here seems to be to have a
    kernel-userspace-boundary that doesn't require a specific kernel
    implementation and works.

    Could someone perhaps make a recap on what are the problems with the
    API? I have no clear eye (experience?) for that (or so it seems).

    > It is a pity that this extra requirement was not clear from your introduction
    > to the "Opportunistic suspend support" patch.

    I think that the main problem was that _all_ the requirements were
    not communicated well. That caused everybody to think that their
    solution would be a better fit. You are not alone.

    > If that be the case, I'll stop bothering you with suggestions that can never
    > work.
    > Thanks for your time,
    > NeilBrown

    Don't be frustrated. What should Arve be? :)

    Cheers,
    Flo


    \
     
     \ /
      Last update: 2010-06-02 21:09    [W:4.274 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site