----- "Michael Holzheu" <holzheu@xxxxxxxxxxxxxxxxxx> wrote: > On Mon, 2010-02-15 at 17:06 +0100, Michael Holzheu wrote: > > > No major changes other than to rename the machdep->elf_note_add() function > > > to machdep->dumpfile_init(). The idea is that, in the future, if there is > > > ever *anything* in *any* type of dumpfile header that should be transmitted > > > to the architecture code during the dumpfile discovery phase, then that function > > > can be used. (For example, I could collaborate all of those machdep->xen_xxx() > > > functions into using it, but I'm not going to bother changing them all > > > at this point...) > > Sorry, I did not read your note carefully. If you want to do that then > my current implementation is wrong. The problem is that now I expect ELF > note structures and will always do. It is not possible to support > multiple dump formats with my current approach. Sure it's possible. In the (unlikely) case s390x ever needs to support anything else, the first int argument can be made a uniquely-identifiable "command" or some such. > My suggestion would be to have one callback per dump format. No thanks. There's now over a dozen different supported dumpfile formats. Your patch is fine. With an int and void * arguments, we can cover all bases in the future. Typically an int would be a command of some sort -- but doesn't have to be as in your case -- and the void * could point to any kind of data structure. I don't want to define things any more than that. Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
