On Saturday, 7 July 2007 14:08, Pavel Machek wrote:
> Hi!
>
> > > Now, if kernel needs FUSE services for some reason (that's the problem
> > > we hit in s2ram case, right?), we have a deadlock.
> > >
> > > So main problem still seems to be "kernel should not depend on
> > > userland services duri
> > One task doing ptrace() can basically do whatever it wants with the
> > task being traced. This is not an exact analogy to what fuse does,
> > but close.
>
> Well, IMO userland tasks should not have power to grab VFS mutexes for
> indefinite ammount of time. ("fused is allowed to deadlock ker
Hi!
> > Now, if kernel needs FUSE services for some reason (that's the problem
> > we hit in s2ram case, right?), we have a deadlock.
> >
> > So main problem still seems to be "kernel should not depend on
> > userland services during suspend", refrigerator or not.
>
> And also "Userland should n
Hi!
> > > > You have processes that don't react to signals, because some
> > > > other user land task is misbehaving. I'd call that ugly at the
> > > > very least.
> > >
> > > It already happens with, say, NFS. Don't think about it in terms of a
> > > userland task misbehaving - think of it in
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, th
> > > You have processes that don't react to signals, because some
> > > other user land task is misbehaving. I'd call that ugly at the
> > > very least.
> >
> > It already happens with, say, NFS. Don't think about it in terms of a
> > userland task misbehaving - think of it in terms of a resour
On Thursday, 5 July 2007 17:03, Matthew Garrett wrote:
> On Thu, Jul 05, 2007 at 05:04:47PM +0200, Rafael J. Wysocki wrote:
> > On Thursday, 5 July 2007 16:39, Matthew Garrett wrote:
> > > Why?
> >
> > You have processes that don't react to signals, because some other user land
> > task is misbeha
On Thu, Jul 05, 2007 at 05:04:47PM +0200, Rafael J. Wysocki wrote:
> On Thursday, 5 July 2007 16:39, Matthew Garrett wrote:
> > Why?
>
> You have processes that don't react to signals, because some other user land
> task is misbehaving. I'd call that ugly at the very least.
It already happens wi
On Thursday, 5 July 2007 16:39, Matthew Garrett wrote:
> On Thu, Jul 05, 2007 at 04:41:39PM +0200, Rafael J. Wysocki wrote:
> > On Thursday, 5 July 2007 16:26, Matthew Garrett wrote:
> > > On Thu, Jul 05, 2007 at 04:28:11PM +0200, Rafael J. Wysocki wrote:
> > > > On Thursday, 5 July 2007 15:57, Mat
On Thu, Jul 05, 2007 at 04:41:39PM +0200, Rafael J. Wysocki wrote:
> On Thursday, 5 July 2007 16:26, Matthew Garrett wrote:
> > On Thu, Jul 05, 2007 at 04:28:11PM +0200, Rafael J. Wysocki wrote:
> > > On Thursday, 5 July 2007 15:57, Matthew Garrett wrote:
> > > > And also "Userland should not depen
On Thursday, 5 July 2007 16:26, Matthew Garrett wrote:
> On Thu, Jul 05, 2007 at 04:28:11PM +0200, Rafael J. Wysocki wrote:
> > On Thursday, 5 July 2007 15:57, Matthew Garrett wrote:
> > > And also "Userland should not depend on userland services", which is
> > > rather more of a problem.
> >
> >
On Thu, Jul 05, 2007 at 04:28:11PM +0200, Rafael J. Wysocki wrote:
> On Thursday, 5 July 2007 15:57, Matthew Garrett wrote:
> > 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.
>
On Thursday, 5 July 2007 15:57, Matthew Garrett wrote:
> On Thu, Jul 05, 2007 at 11:15:26AM +0200, Pavel Machek wrote:
>
> > Now, if kernel needs FUSE services for some reason (that's the problem
> > we hit in s2ram case, right?), we have a deadlock.
> >
> > So main problem still seems to be "ker
On Thu, Jul 05, 2007 at 11:15:26AM +0200, Pavel Machek wrote:
> Now, if kernel needs FUSE services for some reason (that's the problem
> we hit in s2ram case, right?), we have a deadlock.
>
> So main problem still seems to be "kernel should not depend on
> userland services during suspend", refri
Hi!
> > The fact remains that lots of drivers would still need to be changed.
> > In the read and write methods someone would have to add code amounting
> > to this:
> >
> > if (suspend_is_under_way()) {
> > mutex_unlock(...);
> > block_until_resume();
> >
15 matches
Mail list logo
