Richard Moore - RAS Project Lead - Linux Technology Centre.
wrote :-
> If you have ideas/concerns/requirements please make them known.
...
> There are many things we'd like to see
> incorporated, the question is how not to boil the ocean. Here are some of
> the ideas we are thinking about:
>
> Multi-process/multi-thread
> Customisable memory ranges/object types
> Code/Stack/Dynamic allocations
> System Objects:
> File-system
> Memory Management
> Device Management
> Process/Task Management
> (Physical memory ranges)
>
> Multiple (non-fatal) Triggers:
> Trap
> Command
> API
> Automated (via DProbes)
I was aiming at the simplest and in my mind most obvious thing, which
is to have the standard ELF coreer dump handle multiple threads in the
same way as it does on many other systems. The lack of these causes
shrieks of amazement from many of our customers :-(
This is not rocket science, and there are already debuggers (gdb, our
product TotalView, ...) which know how to understand such core dumps
if only the kernel produced them.
Now that the kernel has mechanisms for finding all the threads in a
process, the actual dump writing should be relatively simple. (You
need to write the appropriate register notes for every thread, rather
than just one).
You seem to be aiming for a much more featureful solution (also
applicable to checkpointing ?), I'm simply aiming to catch up with
existing practice on many other operating systems.
-- Jim
James Cownie <jcownie@etnus.com>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:24 EST