Subject: Re: core dump filename format
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 09/07/1999 17:55:58
On Tue, Sep 07, 1999 at 10:45:35AM -0400, der Mouse wrote:
> 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.
> 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?
No, not at all :)
I though p_comm was the same thing as argv. I'll use p_comm, for sure.
> 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).
Good idea. What letters ? :)
> > 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?
Then we would have to create a new syscall anyway, and protect this one
> 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?
It's another option. I though void * would keep binary compat, but it seems
I missed some special machines.
> 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
This should be limited to MAXPATHLEN, isn't it ?
> through the getrlimit() interface, even as
Won't /copyoutstr DTRT ?
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr