> Amount of kernel effort available: minimal
> Ability to invoke debugger with kmod-like trap: questionable
> Ability to invoke debugger with ptrace technology: yes
> Michael's ucore could replace kernel core dumping: maybe
>
> Amount of kernel effort available: extensive
> Ability to invoke debugger with kmod-like trap: yes
> Ability to invoke debugger with ptrace technology: yes
> Michael's ucore could replace kernel core dumping: maybe
>
> For any given level of kernel effort, using ptrace technology gives
> a more powerful result than a kmod-like trap. That's my point.
These aren't the only ways.
I think it would be good to let a crash dump handler open a device file
to get control. Before dumping core, the kernel checks for a crash dump
handler running with the same UID. If one is found, the dying process
sleeps and the crash dump handler is asked to respond.
The crash dump handler could supply a core dump name or start a
debugger to revive the process. Perhaps just leave the process sleeping
and dial tech support on a modem. This could be useful. :-)
Ptrace-like implementations suffer from process relationship problems
and signal handling issues. Kmod-like implementations suffer from the
need to start a complex application as root. It is much nicer to let
an existing user-defined process (GNOME?) select on a device file.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/