Re: [RFC] New Driver Model for 2.5

[Jonathan Lundell]

At 8:53 AM +0100 10/23/01, Alan Cox wrote:
>  > The idea is to allocate all memory in the first pass, disable interrupts,
>>  then save state. Would that work? Or, should some of the state saving take
>>  place with interrupts enabled?
>
>Imagine the state saving done on a USB device. There you need interrupts
>on while retrieving the state from say a USB scanner, and in some cases
>off while killing the USB controller.

Is this a realistic example? That is, is a kernel-side driver likely 
to be able to meaningfully extract state information from a scanner? 
And is it necessary?

And for a scanner, if the current operation is a scan generating a GB 
of data, what happens if the disk subsystem is no longer accepting 
requests?

As Jeff Garzik pointed out, NIC drivers typically don't need to save 
any state at all; it's all recreateable from software structures. 
Perhaps that characteristic can and should be generalized to other 
devices.

In that case, SUSPEND_SAVE_STATE becomes more like SUSPEND_QUIESCE: 
stop accepting new requests, and complete current requests.

"Stop accepting new requests" is nontrivial as well, in the general 
case. New requests that can't be discarded need to be queued 
somewhere. Whose responsibility is that? Ideally at some point where 
a queue already exists, possibly in the requester.
-- 
/Jonathan Lundell.