Re: [Crash-utility] [RFC 0/4] Add support to extract hardware device dumps from vmcore

On Monday, April 04/15/19, 2019 at 21:16:49 +0530, Dave Anderson wrote: > > > ----- Original Message ----- > > Hi Dave, > > > > On Saturday, April 04/13/19, 2019 at 00:39:09 +0530, Dave Anderson wrote: > > > > > > Hi Surenda, > > > > > > Great -- I've been looking forward for this patch set to arrive. > > > > > > A couple things... > > > > > > First, I'm going to need two sample vmcores (one ELF, one compressed kdump) > > > along with the associated vmlinux. You can contact me off-list with details > > > on how we can arrange a transfer. > > > > > > Second, I do not want to add a new command. I rarely do so -- in fact, > > > the only times since the original crash utility was released was in 2012, > > > when the "ipcs" and "tree" commands were added in crash-6.0.7 and > > > crash-6.0.8. > > > New functionality is typically added as an option to an existing command. > > > And in this case, the natural location to put it is in the existing "dev" > > > command, and the devdump_extract() function can be moved into dev.c. > > > (FWIW, you can add your Chelsio copyright at the top of that file) > > > > > > > Ok, thanks for the suggestion. We will move the logic to dev command, > > instead. > > > > We're thinking along the lines of following sample commands: > > > > Display the available device dumps > > crash> dev -v > > INDEX NAME OFFSET SIZE > > 0 cxgb4_0000:02:00.4 0x278 33558464 > > 1 cxgb4_0000:03:00.4 0x2001278 33558464 > > > > Extract device dump at specified index > > crash> devdump -v 0 -f device_dump_0.bin > > 33558464 bytes copied from 0x278 to device_dump_0.bin > > > > Let us know your thoughts. > > Hi Surenda, > > I've got your sample files -- thanks for them, I really appreciate it. > > Here are my thoughts... > > You probably want to make "-V" display the list of available device dumps in the > vmcore, and make "-v <index>" select a singular device for dumping. > Thanks for the suggestion. We will follow this approach. > I also have a question re: the note contents. Is it up to the individual device > as to what format the dump contents are made up of? Are they always binary > dumps, or could a device dump ASCII log data or something to that effect? > They are generally binary in nature. However, it is really up to the individual device to decide the format on how to save its dump contents. > I ask because I see that you are calling display_memory() using these arguments: > > void > display_memory_from_file_offset(ulonglong addr, long count, void *opt) > { > display_memory(addr, count, DISPLAY_RAW | ASCII_ENDLINE | HEXADECIMAL, > FILEADDR, opt); > } > > Since you are using DISPLAY_RAW, display_memory() will simply copy the > note data unmodified directly to the file, and the ASCII_ENDLINE and > HEXADECIMAL arguments are ignored. So it's not clear why you added them? You are correct. It should have been only DISPLAY_RAW. We will fix in next version. > But since you did, I'm now wondering whether it would be useful for > a user to optionally dump a human-readable HEXADECIMAL/ASCII_ENDLINE > formatted display of the data to the screen? If so, then perhaps if > the "-v index" option is used alone *without* a file specified, > why not just do a translated device dump to the screen? We notice that rd command can manipulate the output using below options: rd [-adDxN][-8|-16|-32|-64] Let us know if it is recommended to duplicate above options from rd to dev command for manipulating screen output. We are thinking, dev -v should only be used for doing "full" raw dump to file. Since dev -V already shows offset and size of dump, rd -f can be used for more control over manipulating the dump output to screen or file.

What do you think?