lkml.org 
[lkml]   [1999]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: core files
Ahoj! / Hi!

> On the other side, if some kind of corename patch makes it into the kernel
> and administrator chooses to put all core files e.g to
> /tmp/cores/core.<pid>, then some ucore program can poll on /tmp/cores and
> once it notices a new file created there, just spawn a debugger or whatever
> the user wants (not that I'd like to do it on my machines).
> But such thing should be implemented in userland, why to bloat the kernel.

There's other view possible: why bother having core-dumper in kernel,
when you can have userland process doing it?

Imagine kernel execing /sbin/coredump-him <PID> <dumpable> when
someone needs to dump core. It is both more flexible than current
approach, and probably would save some kernel space (confirmed, saves
4230 bytes of kernel size). Disadvantages are:

* it is slower
...which does not matter: core dumps are slow, anyway, and they
happen rarely

* it will not work without /proc mounted
...not too important because you usualy do not have / readwrite when
/proc is not mounted, so you would not be able to dump core, anyway.

[can not think of more]

I do not know how hard writing of userland coredumper is, mj says it
is possible and not that hard. I do not think this is important... I
may play with it on one cloudy day.

Pavel
--
I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).

-
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:49    [W:0.079 / U:0.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site