>True, it is more difficult, but look at it from another perspective.
>Most of the I/O code involves either the disk driver itself, or some
>intermediary layer. I'd like to throw out most of the request code
>and buffer code in the I/O path, and stick to just writing pages of
>memory (specific ones at that) to the device.
>
>So you'd have a:
>
> dump_write()
> dump_io_write()
> dump_scsi_write() or dump_ide_write()
>
>The last one is simply a frame pointer depending on the dump device
>that is configured. And you still use the standard I/O path for
>checking the partition, making sure it's a valid device, getting
>device information and status, etc., when you call dump_open().
>That way when the crash occurs, all you have to do is use stored
>data from the current dump device tables (sizes, etc.), and just
>write out the pages of memory in some block size format.
>
>The dump I/O driver does only ONE thing; it writes. It doesn't
>need to read, open, close, or any of that. Everything else is
>cached early on during the boot-up process when dump_open() is
>called.
>
>Does that sound legitimate?
We'll need to study some of the low level i/o driver code to see if there
is any way to achieve something like this in a generic way for all scsi
adapters, say (is that what you intended ?) ... but this may be a little
more complicated than it appears at the outset, considering more involved
or specialized driver logic for certain configurations and adapter
characteristics.
There may also be a few additional things to think of (beyond the initial
dump_open). For example there may be a need to suspend/clear other i/o or
reset the dump device if the h/w was in use by the running system, before
dump can start. There would have to be some way to determine when a write
has completed (typically poll mode or in some way that avoids using the
system's interrupt handling code) so that the next write request can be
sent. All of this code shouldn't share any state with the standard driver.
AIX has a dump interface architected for device drivers, a little like what
you suggest, but we weren't sure how feasible it would be to provide
something of that sort on linux, considering the range of hardware and
third party drivers to consider. Did you have some feedback from driver
maintainers about this ? I remember you had once mentioned that Linus had
suggested the need for a raw dump i/o interface during earlier discussions
about incorporating lkcd into the kernel.
I'll be away at OLS and on vacation for a week after that, so will continue
these discussions then.
Bharata will be around, though.
Regards
Suparna
Suparna Bhattacharya
IBM Software Lab, India
E-mail : bsuparna@xxxxxxxxxx
Phone : 91-80-5267117, Extn : 2525
|