Messages in this thread |  | | | From | "Rafael J. Wysocki" <> | | Subject | Re: Hibernation considerations | | Date | Fri, 20 Jul 2007 12:59:42 +0200 |
| |
On Friday, 20 July 2007 06:40, Al Boldi wrote: > Rafael J. Wysocki wrote: > > On Wednesday, 18 July 2007 16:29, Alan Stern wrote: > > > > > > Never mind. It seems clear that this approach will suffer the same > > > drawback as the proposal for removing the freezer from the > > > suspend-to-RAM pathway. Namely, device drivers will have to be changed > > > to prevent user I/O requests from proceeding while devices are supposed > > > to be quiescent or in a low-power state. > > > > I agree. > > > > > If a driver fails to handle this properly, its device could be > > > reactivated in order to service a user request before the memory > > > snapshot is made. This could easily ruin the snapshot. > > > > That's why I've been saying for quite some time that we first need to take > > care of the drivers. :-) > > > > IMO we've reached the point at which, whatever we want to do next, the > > drivers are in the way. > > Correct, but only if we want ACPI support.
No, in general.
> Granted, we need a separation of > the hibernate/suspend PM functions, but in the absence of ACPI, all we need > right now are dump/restore routines for the crashkernel.
IMO you aren't right, but I guess there's no point in trying to convince you.
> Next, we should be looking into reducing the kexec'd kernel environment size, > which currently, at 16MB, is way too big, and even at 1MB would be > problematic for small systems. > > So, ACPI should really be the least of our worries, and the reason why people > are fixating on ACPI is probably because they have nothing else to fixate > on.
Yeah, right. Please read the $subject message again. And sorry, but IMO your previous replies to it haven't addressed any of the original points.
Greetings, Rafael
-- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |