Re: [RFC] New Driver Model for 2.5

Jonathan Lundell (jlundell@pobox.com)
Tue, 23 Oct 2001 08:10:15 -0700


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.
-
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/