Messages in this thread | | | Date | Sat, 2 Jan 1999 21:43:20 +0100 | From | Pavel Machek <> | Subject | Re: 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/
| |