> > Indeed. Actually, one could argue that it's impossible to solve the
> > problem as long as we try to call out to userspace during suspend and
> > need to wait until that's finished, like in the case of sys_sync() and
> > fuse filesystems, and probably other cases. Maybe we should make *those*
> > calls return a failure so that the suspend isn't transparent inside the
> > kernel but is transparent to userspace.
> Well, it generally needs more consideration. :-)
> I think that we should introduce mechanisms that will allow us to notify all
> kernel subsystems, including FUSE and similar, that the system is going to
> enter a sleep state (one of those is the notifier chain introduced recently).
Ugh, please no.
Believe me, fuse is doing _nothing_ out of the ordinary, and should
not need special treatment during suspend/resume. If suspend itself
is doing something that triggers fuse activity, then that's a bug,
such as the sync() thing that started this thread.
> Then, they may react to such a notification by entering a "suspend" mode
> of operation in which they will return errors from some callbacks that
> otherwise should have succeeded etc. That depends on the subsystem in
Why do we need to deal with subsystem interdependencies during
suspend? Isn't it about saving device state to ram? That definitely
_should not_ need to trigger anything that touches filesystems or
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Video 4 Linux]
[Linux for the blind]