> Following Bill Sommerfeld's idea of "core dump filename format", here
> is a more formal proposal:

> 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

The traditional thing like %n (p->p_comm) is more like basename() of
the file that was execed (truncated if it's long), which does not
necessarily bear any relation to argv[0].

I can't see any decent way to implement %u; I don't think the kernel
has user names available.  Or were you proposing to define an interface
by which this could be changed?

Another potentially useful format would be one that would get the
signal that caused the core.  This could be either name or number,
preferably with both forms available (unlike user names, compiling a
table of signal names into the kernel is (a) possible and (b) not
especially bloatful, only a few hundred bytes).

> The default value would be %s.core,

Presumably you mean %n.core. :-)

> 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 *,

I'm not sure I like this; it breaks binary compatability on machines
where struct pointers and void pointers don't "smell the same" (eg, are
different sizes).  Does NetBSD currently run on any such machines?

It also loses the typechecking the present prototype gives.

Perhaps instead, a char * pointer could be added to struct rlimit, with
the syscall versioned to provide full binary compatability?

On reflection, I'm not sure this belongs with struct rlimit.  Perhaps a
top-level MIB item could be added to sysctl(3) and/or __sysctl(2) for
per-process stuff, like this?  Obviously it wouldn't be much use via
sysctl(1), but it would be a fine for this, and I daresay more uses
would come along.  ([gs]etrlimit could be turned into wrappers around
__sysctl() calls, for example, as could other such calls that can't
affect any but the current process.)

It would also sidestep the question of how to return a string of more
or less unlimited length through the getrlimit() interface, even as
extended.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B