In article <19990907151243.A911@antioche.eu.org>,
Manuel Bouyer <bouyer@antioche.lip6.fr> wrote:

>I propose to add a per-process inherited attribute, which would define
>the name of the core file.
>I can see 3 usefull formats:
>%n: name (argv[0]) of the process
>%p: the pid of the process
>%u: name of the user
>
>Idea for other formats are welcome.
>
>The default value would be %s.core, but can be changed at runtime by a sysctl.
>Absolute path are allowed, as something like: "/var/core/%u/%n.core"
>kern.shortcorename would disappear, as the same thing can be achieved
>with kern.corename="core".

One feature I always wanted was to have core dump files be created
uniquely.  I.e. if a programs keeps core-dumping, I'd like to keep
all the core dumps.  Now this brings us closer to that direction
using %n.%p.core, but still %p is not unique. I don't want to put
the timestamp [ticks] in there, but what else can be there? %t
could be ok if someone does not come up with a better idea.

>As this attribute is really close to process limits, I plan to extend
>getrlimit/setrlimit with a new resource type (Otherwise a new syscall would
>need to be created for this purpose). They would now take a void * parameter,
>which would be a struct rlimit * or char *, depending on the resource type.
>In the kernel this attribute would be added to "struct plimit".
>
>Then each shell will be updated to allow users to set this new "limit".
>
>Comments ? I'm planning to start coding on this soon, shouldn't require
>much work.

I don't like the get/set/rlimit overloading. I think that adding one
system call such as corefile(2), with corefile(CORE_GET, char *) and
corefile(CORE_SET, const char *), seems better to me, unless there is
prior art we should follow.

Also one should consider the stickyness of this. Should it be reset
across setuid exec's like resource limits are? I think so.

christos