From: Pavel Machek <pavel@ucw.cz>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Kernel development list <linux-kernel@vger.kernel.org>,
Johannes Berg <johannes@sipsolutions.net>,
Linux-pm mailing list <linux-pm@lists.linux-foundation.org>
Subject: Re: removing refrigerator does not help with s2ram vs. fuse deadlocks (was Re: Re: [PATCH] Remove process freezer from suspend to RAM pathway)
Date: Sat, 7 Jul 2007 13:49:47 +0200 [thread overview]
Message-ID: <20070707114947.GD2789@elf.ucw.cz> (raw)
In-Reply-To: <20070705142600.GB22598@srcf.ucam.org>
Hi!
> > > And also "Userland should not depend on userland services", which is
> > > rather more of a problem.
> >
> > I think you're oversimplifying it, as far as FUSE is concerned.
> >
> > Namely, if there are two userland tasks, A and B, and B is uninterruptible,
> > because A is blocked, then this is not a usual situation.
>
> Fuse is one case of it occuring, and if we end up with more userspace
> drivers then the problem is only going to get worse.
We'll have to solve them as they come.
Face it, hardware drivers _have_ to know about suspend/resume. Even
userspace drivers will have to know about suspend/resume, because they
need to reinit the hw during resume.
Now... most parts of kernel need to know (a bit) about suspend/resume
-- at least enough to play nicely with refrigerator. In retrospect it
is pretty obvious that this covers fused, too, unfortunately noone
noticed that when fuse was designed.
Can we try to solve the suspend vs. fuse problem now? "Just removing
the refrigerator" is not the answer. First, refrigerator is impossible
to remove in few months timeframe, and second, it does not solve the
problem anyway.
(Actually, there are two separate problems with suspend vs. fuse.)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2007-07-07 11:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <18059.6726.218205.104212@cargo.ozlabs.ibm.com>
2007-07-04 15:12 ` Re: [PATCH] Remove process freezer from suspend to RAM pathway Alan Stern
[not found] ` <Pine.LNX.4.44L0.0707041104140.25704-100000@netrider.rowland.org>
2007-07-05 0:35 ` Paul Mackerras
2007-07-05 9:15 ` removing refrigerator does not help with s2ram vs. fuse deadlocks (was Re: Re: [PATCH] Remove process freezer from suspend to RAM pathway) Pavel Machek
[not found] ` <20070705091526.GA3084@elf.ucw.cz>
2007-07-05 13:57 ` Matthew Garrett
[not found] ` <20070705135758.GB22177@srcf.ucam.org>
[not found] ` <200707051628.12199.rjw@sisk.pl>
2007-07-05 14:26 ` Matthew Garrett
[not found] ` <20070705142600.GB22598@srcf.ucam.org>
2007-07-05 14:41 ` Rafael J. Wysocki
2007-07-05 14:39 ` Matthew Garrett
[not found] ` <20070705143918.GA23248@srcf.ucam.org>
[not found] ` <200707051704.48137.rjw@sisk.pl>
2007-07-05 15:03 ` Matthew Garrett
[not found] ` <20070705150301.GB23647@srcf.ucam.org>
2007-07-05 15:27 ` Rafael J. Wysocki
[not found] ` <200707051727.36715.rjw@sisk.pl>
2007-07-05 15:32 ` Miklos Szeredi
[not found] ` <E1I6TJq-000164-00@dorka.pomaz.szeredi.hu>
2007-07-07 11:50 ` Pavel Machek
2007-07-07 20:14 ` Miklos Szeredi
2007-07-05 15:04 ` Rafael J. Wysocki
2007-07-07 11:49 ` Pavel Machek [this message]
2007-07-05 14:28 ` Rafael J. Wysocki
2007-07-07 12:08 ` problem 1 (was Re: removing refrigerator does not help with s2ram vs. fuse deadlocks (was Re: Re: [PATCH] Remove process freezer from suspend to RAM pathway)) Pavel Machek
[not found] ` <20070707120827.GA3111@elf.ucw.cz>
2007-07-07 20:55 ` Rafael J. Wysocki
2007-07-05 14:42 ` Re: [PATCH] Remove process freezer from suspend to RAM pathway Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070707114947.GD2789@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=mjg59@srcf.ucam.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox