On Wed, 10 Oct 2001, Masashige Kotani wrote:
|>Hi, Matt.
|>
|>I'd like to know more about dump methods.
|>Could you give me further information about below 3 points ?
|>
|>Because we are planning to support of multiple dump devices as shown in
|>former mail
|>(Message-ID:<006201c13518$869ce140$d64817ac@xxxxxxxxxxxxxxxxxxx>),
|>I want to consider the program composition being conscious of
|>module structure of dumping method.
|>
|>
|>Point 1: relation of dump devices and dump methods
|>
|>from Message-ID: <3B9563E8.9A432B7B@xxxxxxxxxxxxxx>:
|>
|>> Here's where I'm going with this. I just finished the code to allow
|>> people to install their own dump compression mechanisms (right now, it'll
|>> be RLE, I have to check in the GZIP compression module, and people can
|>> put in whatever one they want). Do you want to take the next step and
|>> let people have chains of dump mechanisms based on the dump condition?
|>> I realize multiple dump devices is good, but what if you could plug in
|>> your own dump method with it? Then that dump method could query the
|>> available dump devices configured.
|>>
|>> So you'd have:
|>>
|>> dump methods (one standard, but plug-and-play)
|>> dump devices (requires at least one, multiples allowed, maybe
|>> access lists for methods?)
|>> dump compressions (configurable, usable by some methods)
|>>
|>> Would this be the eventual goal? That way, everything is tunable to
|>> their own liking. I figured I'd ask, since if you're going to add in
|>> multiple dump devices, and we've gone to multiple compression types,
|>> you might as well go all the way and add dump methods as well. I
|>> don't know what the rest of the group thinks, but this could be
|>> very useful.
|>
|>I'm not sure about "maybe access lists for methods?".
|>Please give me further description.
|>
|>For example, I want to know the relation between "dump devices" and
|>"dump methods".
|>
|>Does each dump method register dump devices ?
|> For example
|> methodA : /dev/sda5 & /dev/sda6 & /dev/sda7
|> methodB : /dev/sda8 & /dev/sda9
|>
|>Or, Does each dump device register dump method ?
|> For example
|> /dev/sda5 : mothodA
|> /dev/sda6 : mothodA
|> /dev/sda7 : mothodA
|> /dev/sda8 : mothodB
|> /dev/sda9 : mothodB
I was proposing this one. Dump devices (/dev/dump/dump1, for
example) refers to a dump disk method, followed by either a
dump device, network address, or whatever the storage location
might be, and any flags, etc.
/dev/dump becomes a directory, /dev/dump/dump[0-N] becomes the
base dump device for performing open()s, ioctl()s, close()s, etc.
|>Or, Does each dump method share all dump devices?
|> For example
|> shared dump devices : /dev/sda5 & /dev/sda6 & /dev/sda7
|> methodA : from shared dump devices
|> methodB : from shared dump devices
|>
|>Or, the other way?
|>
|>
|>Point 2: Saving to dump file
|>
|>How about lcrash?
|>If you make own dump method module, you have to build the function
|>dealing with the dump method in lcrash ?
|>Or, should lcrash have the ability of adding function the same as
|>kernel module ?
All that would be added to the dump header or some identifier so
that 'lcrash' can decipher the dump methodology. I think a
universal dump header is a good thing to have.
|>Point 3: How does it goes ?
|>
|>Do you have any plans to complete this facility ?
This is for the 5.0 time frame. 4.0 is basically done. I'm all
for getting this done in the 5.0 release. We have to finish the
dump() device driver implementation for at least IDE first before
we implement this.
Thanks, Masashige-san. I hope this E-mail doesn't arrive too
late for any planning needs you may have.
--Matt
|>Regards,
|>Masashige
|