lkml.org 
[lkml]   [1998]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: core files

    > Michael Elizabeth Chastain writes:

    > 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/

    \
     
     \ /
      Last update: 2005-03-22 13:46    [W:0.022 / U:0.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site