[lkml]   [2001]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] New Driver Model for 2.5

> >We should not have pending IO, but that's for a totally different reason:
> >the first thing the much much MUCH higher levels of suspend should be
> >doing is to make sure that user apps are "quiescent". And that isn't done
> >by getting involved with sg.c or anything similar, but by basically
> >stopping all user apps (think of the equivalent of a "kill -STOP -1", but
> >done internally in the kernel without actually using a signal).
> Is this necessary ? That would definitely make things easier to implement
> to forget about incoming requests, but I'm not sure it's the right way.
> In fact, is it really working ? You could well have in-kernel threads
> triggering IOs or launching new userland stuffs (what happens if a not
> yet suspended driver for, let's say USB, see a new device coming in
> and starts /sbin/hotplug). Some filesystems have garbage collector threads
> that can do IOs eventually. There are various kind of IOs that can in fact
> be triggered entirely within the kernel.

I need this for suspend to disk. I really need quiescent system if I
want to write to swap image, right?

I implemented a "refrigerator" mechanism, and manually marked threads
that should not be frozen. I'm doing my best to stop everyone who
might try to wake userland.

[I just mailed the patch as 2.4.13 - swsusp. Tell me if you want a

STOP THE WAR! Someone killed innocent Americans. That does not give
U.S. right to kill people in Afganistan.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:10    [W:0.233 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site