8:14 a.m.
Fujitsu has stand-alone dump mechanism based on firmware level
functionality, which we call SADUMP, in short.
We've maintained utility tools internally but now we're thinking that
the best is crash utility and makedumpfile supports the sadump format
for the viewpoint of both portability and maintainability.
We'll be of course responsible for its maintainance in a continuous
manner. The sadump dump format is very similar to diskdump format and
so kdump (compressed) format, so we estimate patch set would be a
relatively small size.
Could you tell me whether crash utility and makedumpfile can support
the sadump format? If OK, we'll start to make patchset.
Thanks.
HATAYAMA, Daisuke
7:57 a.m.
----- Original Message -----
Fujitsu has stand-alone dump mechanism based on firmware level
functionality, which we call SADUMP, in short.
We've maintained utility tools internally but now we're thinking that
the best is crash utility and makedumpfile supports the sadump format
for the viewpoint of both portability and maintainability.
We'll be of course responsible for its maintainance in a continuous
manner. The sadump dump format is very similar to diskdump format and
so kdump (compressed) format, so we estimate patch set would be a
relatively small size.
Could you tell me whether crash utility and makedumpfile can support
the sadump format? If OK, we'll start to make patchset.
Sure, yes, the crash utility can always support another dumpfile format.
It's unclear to me how similar SADUMP is to diskdump/compressed-kdump.
Does your internal version patch diskdump.c, or do you maintain your
own "sadump.c"? I ask because if your patchset is at all intrusive,
I'd prefer it be kept in its own file, primarily for maintainability,
but also because SADUMP is essentially a black-box to anybody outside
Fujitsu.
Thanks,
Dave
Thanks.
HATAYAMA, Daisuke
8:14 a.m.
From: Dave Anderson <anderson(a)redhat.com>
Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
Date: Tue, 28 Jun 2011 08:57:42 -0400 (EDT)
----- Original Message -----
> Fujitsu has stand-alone dump mechanism based on firmware level
> functionality, which we call SADUMP, in short.
>
> We've maintained utility tools internally but now we're thinking that
> the best is crash utility and makedumpfile supports the sadump format
> for the viewpoint of both portability and maintainability.
>
> We'll be of course responsible for its maintainance in a continuous
> manner. The sadump dump format is very similar to diskdump format and
> so kdump (compressed) format, so we estimate patch set would be a
> relatively small size.
>
> Could you tell me whether crash utility and makedumpfile can support
> the sadump format? If OK, we'll start to make patchset.
Sure, yes, the crash utility can always support another dumpfile format.
Thanks. It helps a lot.
It's unclear to me how similar SADUMP is to
diskdump/compressed-kdump.
Does your internal version patch diskdump.c, or do you maintain your
own "sadump.c"? I ask because if your patchset is at all intrusive,
I'd prefer it be kept in its own file, primarily for maintainability,
but also because SADUMP is essentially a black-box to anybody outside
Fujitsu.
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.
On the other hand, there's a code to be placed at such specific
area. sadump is triggered depending on kdump's progress and so
register values to be contained in vmcore varies according to the
progress: If crash_notes has been initialized when sadump is
triggered, sadump packs the register values in crash_notes; if not
yet, packs registers gathered by firmware. This is sadump specific
processing, so I think putting it in specific sadump.c file is a
natural and reasonable choise.
Anyway, I have not made any patch set for this. I'll post a patch set
when I complete.
Again, thanks a lot for the positive answer.
Thanks.
HATAYAMA, Daisuke
370
days inactive
370
days old
devel@lists.crash-utility.osci.io
2 comments
2 participants
participants (2)
-
Dave Anderson -
HATAYAMA Daisuke