[lkml]   [2001]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] New Driver Model for 2.5
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

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

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:10    [W:0.135 / U:0.012 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site