> Why would you _ever_ get "sg.c" and other crap involved in the suspend
> process?
>
> The device tree is for _device_ suspend, not for "subsystem suspend". The
> SCSI subsystem is a piece of cr*p, but even if it was perfect it should
> never get involved with the act of suspension.
Well I don't want my laptop to suspend during a CD burn or firmware update.
The device itself doesn't know anything about how busy it is since its
just sending packets, only the subsystem driver controller it does
> 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).
Stopping all user apps really tends to ruin the cd and the firmware
update.
> Remember: the main point of suspend is to have a laptop go to sleep, and
> come back up on the order of a few _seconds_.
It also has to avoid unpleasant situations
> Also, realize that the act of suspension is STARTED BY THE USER. Which
> means that before the kernel suspends, you _can_ have user programs that
> basically take disk arrays off-line etc if that is what you want. But
> that's not ae kernel suspend issue.
There are certain practicalities here with trying to make user space dig
around in fuser innards or patching every cd burner. The sg layer is one
that has to get involved (be it as a driver call back or a virtual driver)
-
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/
This archive was generated by hypermail 2b29 : Wed Oct 31 2001 - 21:00:23 EST