3:56 p.m.
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com> 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
4:34 a.m.
New subject: [PATCH] Add ELF core dump support for s390x
Dave,
On Mon, 2010-02-15 at 16:56 -0500, Dave Anderson wrote:
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com>
wrote:
> 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.
First of all: It is VERY likely that we will support a new dump format
in the near future. Believe me.
Second, how should that work? The callback has an integer and a void
pointer. The integer is currently used to specify the CPU number. The
void pointer is used to hold the ELF note information. How the hell can
I code the information for a new dump format. Or am I missing something?
Michael
4:59 a.m.
New subject: [PATCH] Add ELF core dump support for s390x
On Tue, 2010-02-16 at 11:34 +0100, Michael Holzheu wrote:
Dave,
On Mon, 2010-02-15 at 16:56 -0500, Dave Anderson wrote:
> ----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com> wrote:
> > 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.
First of all: It is VERY likely that we will support a new dump format
in the near future. Believe me.
Second, how should that work? The callback has an integer and a void
pointer. The integer is currently used to specify the CPU number. The
void pointer is used to hold the ELF note information. How the hell can
I code the information for a new dump format. Or am I missing something?
What we could do is to add a third parameter e.g. an enum that indicates
the dump format.
enum crash_dump_fmt {
DUMP_FMT_ELF,
DUMP_FMT_KDUMP,
...
Michael
5397
days inactive
5398
days old
devel@lists.crash-utility.osci.io
2 comments
2 participants
participants (2)
-
Dave Anderson -
Michael Holzheu