On Mon, Oct 08, 2001 at 11:46:42PM -0700, Matt D. Robinson wrote:
>
> I absolutely think 5 should be common -- that way the driver has
> little to think about. If each device driver is given the option
> to dump in its own unique way (beyond location/size/time/etc),
> that could lead to 5 needing to know whether it's talking to an
> IDE or SCSI driver, for example.
>
> Sounds good ...
>
> > Any other comments / observations / experiences to share ?
>
> I think you've covered most of it. The real key here is making sure
> to maintain as little stuff as possible in the dump functionality for
> each device driver. That device operation is responsible for knowing
> what to do when it is called, in terms of configuring the driver
> state, reading flags, and writing out pages of data to disk. For it
> to do more than that, such as understanding higher level kernel
> structures,
> would not be a good thing.
Exactly !
That was the reason for trying to outline the tasks - so we can bring up
common stuff into the generic dump functionality, providing more control
& flexibility in the fray.
So the write call, 3 is just essentially asynchronous (doesn't do any polling
- but just initiates the i/o) and polling/waiting happens through the
common dump code (rather than in the driver) as part of 5, which calls
4 (implemented in the driver) to check for completion ( perhaps
optionally ask it to wait for completion within legitimate bounds ?).
Regards
Suparna
|