----- Original Message -----
Now I am confused...
You stated this earlier:
> What I meant when I used ``similar'' is both literally and
> logically. The format consists of diskdump header-like header, two
> kinds of bitmaps used for the same purpose as those in diskump format,
> and memory data. They can be handled in common with the existing data
> structure, diskdump_data, non-intrusively, so I hope they are placed
> in diskdump.c.
which made it sound like the sadump dumpfile format is already similar
to the compressed kdump format.
But this makes it sound like the sadump native-format is unique:
> >> The first is to translate sadump format into the one crash utility can
> >> recognize. makedumpfile is the standard tool to do it, and if
> >> makdumpfile can support sadump format, I think it is the best.
> >>
> >> > - It isn't possible to support the same form as kdump-compressed format
> >> > now, is it?
> >>
> >> I think it's technically possible but practically impossible. sadump is
> >> a firmware and it is maintained by firmware team.
Is this how it would work?:
(1) kernel crashes
(2) sadump creates a native-format dumpfile
(3) (patched) makedumpfile takes the native-format sadump dumpfile and
translates into a format that is similar to a compressed kdump
(4) (patched) crash utility reads the translated sadump dumpfile
Or will the (patched) crash utility be able to read the sadump dumpfile
in its native form if it is not pre-processed by makedumpfile?
Dave
