bsuparna@xxxxxxxxxx wrote:
>
> >If you're talking about non-disruptive dumps here, I agree.Otherwise,
> >I'm not so certain. I don't believe you should wait for anything.Stable
> >system state when panic() or die_if_kernel() is activated is completely
> >ambiguous. Therefore, you should start acting right away,regardless of
> >system state.
>
> Yes, we were talking about non-disruptive dumps in the note. I understand
> your concern about panic type situations. That needs more thought.
>
> >If you're using your own I/O driver for dumping, then it eliminates the
> >uncertainty associated with disruptive dumps.
>
> Assuming that you are talking only about panic type/disruptive dumps here
> (not the non-disruptive case, right ?).
> One problem with the specialized i/o driver approach is that it may be hard
> to get this support for all kinds of disk i/o / dump h/w (all adapter
> types). So, we would need to address the cases where such a raw interface
> does not exist for the dump device and have a fall-back aproach for these
> cases (mcore style ?)
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?
> Regards
> Suparna
>
> Suparna Bhattacharya
> IBM Software Lab, India
> E-mail : bsuparna@xxxxxxxxxx
> Phone : 91-80-5267117, Extn : 2525
--Matt
|