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[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?

No, not at all :)
I though p_comm was the same thing as argv[0]. 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
under 'compat_14'

> 
> 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
> extended.
> 

Won't /copyoutstr DTRT ?


--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--