ps_strings

Konstantin Belousov kostikbel at gmail.com
Tue Aug 20 20:46:13 UTC 2013


On Mon, Aug 19, 2013 at 06:49:55PM -0600, Chris Torek wrote:
> >Yes, p_args caches the arguments, but not always.  Right now, kernel
> >does not cache arguments if the string is longer than 256 bytes.  Look
> >for ps_arg_cache_limit in kern_exec.c.
> >
> >setproctitle() always informs the kernel with sysctl and sets the
> >pointers in ps_strings. kern.proc.args sysctl first tries the p_args,
> >and falls back to reading ps_strings and following the pointers if
> >p_args is NULL.
> 
> Ah, that's what I get for scanning through years of updates too fast.
> :-)
> 
> This seems a bit of a "worst of both worlds": there's now some
> extra kernel code for poking through the ps_strings and the
> pointer-vectors (this code is no longer in libkvm at all --
> that was where I looked first and found the sysctl), for the "no
> p_args" case.  It seems like perhaps there could just be a sysctl
> to return the ps_strings address, and leave the "follow argv
> pointers" code in libkvm, if there is to be code for that.
There is a demand for other things besides arguments, e.g. environment,
and most important for the debuggers, ELF aux vector. Also, moving
this code to libkvm would mean that mismatched ABIs cannot be easily
supported, like 64bit binary trying to get 32bit binary information.

I would say that the current placement fullfill its goals.
> 
> (The kernel saves a bit of time for the presumably-usual "p_args
> not NULL" case, and finding the location of the ps_strings
> structure when it *is* used is automatically correct.  So that
> part is a straight-up improvement, at least.)
> 
> Not that big a deal either way, but it does seem as though there
> should be documentation for ps_strings.
> 
> Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20130820/7775f595/attachment.sig>


More information about the freebsd-hackers mailing list