Quite; I wouldn't bother.
Some other suggestions: instead of patching all binfmt_*.c files,
have a common core name generation function which the individual
core dumpers call.
Rather than having a CONFIG option to exclude the dumpers altogether,
have an option to either have just the simple "core" name, or all
the new functionality.
Another idea is to have a /proc/sys/kern/coredump file which you
can cat a format string into to generate a name. While I think this
is excessive bloat, it may be useful to something. For example:
%p - pid
%e - executable name
%s - sequence number (incremented every coredump since boot time)
%d - timestamp (decimal seconds since epoch; no need for full time/date
formatting).
%% - traditional '%'
[ Note, these are just made up on the spot; one could probably argue
for better codes, but that's just detail. ]
Then you could do things like:
echo core > coredump # traditional behaviour
echo core.%e > coredump # For those who like it
echo %e.core > coredump # And the others
echo %e.core.%s.%p.%d > coredump# Just because we can
As I said, I think this is unjustifiable bloat, but people obviously
get excited by this, and a solution like this allows them do do things
without having the kernel define a policy which will make someone upset.
It should definitely be a config option.
Note that '%s' overrides the need for an "inhibit core overwrites",
especially with '%d' (unless you're playing with your system time a
lot).
I don't see a need for root-only coredumps or enabling or disabling:
both these can be done already with the limits interface.
J