On Mon, 2007-07-09 at 11:23 +0200, Oliver Neukum wrote: > Suspension is to be transparent. Apart from a jump in the system clock > user space must not notice, thus returning errors due to suspension is > not an option. Who says ? If I'm talking to a USB printer, it will notice the USB bus being suspended, believe me. It's actually likely to screw up whatever job is in progress. It make perfect sense to error out attempts to talk to it when suspended. I don't think "transparent" is an absolute requirement. In some cases, it doesn't make sense and the printer is a good example of that. The printing daemon is typically something that will ideally need to grow knowledge about suspend/resume to interrupt things at the right time. That's one of the thing... we don't even have the kernel right, so we are light-years from having the rest of userland right. For example, from a user point of view, what should happen if you suspend while printing ? Well, it's a matter of policy (thus should be configurable), but I would exect (as a former Mac user) something around the lines of this as a default: - If the laptop's clamshell has been closed, it's likely that the user's just picking up the laptop for a ride, makes sense to abort jobs in progress. - If this is a manual action via the menus, displaying a dialog asking if you really want to suspend before your page is finished makes sense (with that dialog disappearing and the machine going to sleep if you just wait and let it print). That sort of thing requires much more than just kernel collaboration of course, but a whole infrastructure in userland as well. So no, suspend is -not- transparent, doesn't have to be, it's something that is to be decided on a case-by-case basis (or rather, driver-per-driver and possibly via policy settings). Ben. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
