All of lore.kernel.org
 help / color / mirror / Atom feed
From: tachibana@mxm.nes.nec.co.jp
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: kexec@lists.infradead.org, crash-utility@redhat.com
Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
Date: Thu, 30 Jun 2011 14:58:46 +0900	[thread overview]
Message-ID: <20110630145846tachibana@mail.jp.nec.com> (raw)

Hi Hatayama-san,

On 2011/06/29 12:12:18 +0900, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
> From: Dave Anderson <anderson@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.

I think it's not bad to support sadump by makedumpfile. However I have 
several questions.
- Do you want to use makedumpfile to make an existing file that sadump has 
  dumped small?
- It isn't possible to support the same form as kdump-compressed format 
  now, is it?
- When the information that makedumpfile reads from a note of /proc/vmcore 
  (or a header of kdump-compressed format) is added by an extension of 
  makedumpfile, do you need to modify sadump?

Thanks
tachibana


> > 
> > 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
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

             reply	other threads:[~2011-06-30  6:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-30  5:58 tachibana [this message]
2011-06-30  7:25 ` [Crash-utility] [RFI] Support Fujitsu's sadump dump format HATAYAMA Daisuke
2011-06-30  8:24   ` tachibana
2011-06-30  8:38     ` HATAYAMA Daisuke
2011-06-30 13:40       ` Dave Anderson
2011-07-01  1:09         ` HATAYAMA Daisuke
  -- strict thread matches above, loose matches on Subject: below --
2011-06-28  7:44 HATAYAMA Daisuke
2011-06-28 12:57 ` [Crash-utility] " Dave Anderson
2011-06-29  3:12   ` HATAYAMA Daisuke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110630145846tachibana@mail.jp.nec.com \
    --to=tachibana@mxm.nes.nec.co.jp \
    --cc=crash-utility@redhat.com \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=kexec@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.