Messages in this thread | | | Date | Sat, 20 Oct 2001 03:01:38 +1000 | Subject | Re: [RFC] New Driver Model for 2.5 | From | Kevin Easton <> |
| |
Hi,
Am I correct in thinking that the current "state of play" after these recent discussions is a 3 step suspend process, following an algorithm similar to:
if (suspend_prepare(device_list) == failed) { suspend_cancel(device_list); return failed; }
if (suspend_save_state(device_list) == failed) { suspend_cancel(device_list); return failed; }
write_out_state(); suspend_now(device_list);
Where these operations on the drivers are defined as:
suspend_prepare: Allocate any memory needed for saving of state, suspending & resuming device. LAST CHANCE TO ALLOCATE MEMORY.
suspend_save_state: Stop accepting requests. Save state of device.
suspend_now: Turn off device.
suspend_cancel: Free any memory that may have been allocated for saving of state. Resume normal operation.
...and write_out_state() somehow stores the saved (in memory) state of the devices to nonvolatile storage.
If this is approximately the right idea, then how will write_out_state work if the device(s) that this operation uses aren't accepting requests anymore (because they've done suspend_save_state)? Is it that "Stop accepting requests" is actually "Stop accepting requests that will cause a change in the device state"? In that case, devices that can have the state written out to them will be limited to those where the act of writing it out will never cause such a request, right?
- Kevin.
- 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/
| |