Hi Hatayama-san, On 2011/06/29 12:12:18 +0900, HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote: > From: Dave Anderson <anderson at 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 at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec
