> Date: Sun, 25 Feb 1996 12:06:37 -0700
> From: Warner Losh <imp@village.org>
> To: Linus Torvalds <Linus.Torvalds@cs.helsinki.fi>
> Cc: Carsten Paeth <calle@calle.in-berlin.de>, hpa@storm.net,
> submit-linux-dev-kernel@ratatosk.yggdrasil.com
> Subject: Re: renaming core dumps
>
> : Anyway, I could live with a config option too, but I do not really see
> : the reason for it. The fact that gdb dumped core on somebody is
> : unfortunate, but not a catastrophy (you can just re-do the core-file,
> : after all, total time loss 1 minute).
>
> Linus,
> I do respect your opinion, however, that is not always the
> case. It can be hard to recreate core files, which is why having gdb
> dump core all over them is a bad idea. I have litterally had core
> files that took *DAYS* to reproduce. Having gdb dump core on them
> would take me a week to recover from. Granted, I can rename these
> core files, but your basic premise here isn't always correct. I know
> you don't value core files, but having been in industry several years
> has taught me they can be quite valuable sometimes, even if 99% of the
> time they are of minimal value.
Yes, and that last 1% is the important one.
>
> On my FreeBSD system, the core file renaming has been quite
> useful. There have been times that I have had multiple deamons dump
> core at the same time. All of the core files were preserved because
> they were named differently. Granted, this filled up /, but I was
Anyone running with insufficient room in / should be shot. :-)
I leave a good 20 meg leeway in case /tmp dosn't get mounted (on a single
user system)
> My point is that a config option would make sense.
memcpy(corefile,"core.",5);
#if 0
memcpy(corefile+5,current->comm,sizeof(current->comm));
#else
corefile[4] = '\0';
#endif
If linus won't make a config option, change the #if 0.
(linux/fs/binfmt_(elf/aout).c
This is such a low-maintenence section that it is unlikly to reject diffs.
(unless it becomes a config option)
--Dan