Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Aug 2013 23:46:06 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Chris Torek <torek@torek.net>
Cc:        freebsd-hackers@freebsd.org, Carlos Jacobo Puga Medina <cjpugmed@gmail.com>
Subject:   Re: ps_strings
Message-ID:  <20130820204606.GQ4972@kib.kiev.ua>
In-Reply-To: <201308200049.r7K0ntT4012366@elf.torek.net>
References:  <20130819074452.GW4972@kib.kiev.ua> <201308200049.r7K0ntT4012366@elf.torek.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--Lnsp2IoRaSbaVT9J
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> Ah, that's what I get for scanning through years of updates too fast.
> :-)
>=20
> 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.
>=20
> (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.)
>=20
> Not that big a deal either way, but it does seem as though there
> should be documentation for ps_strings.
>=20
> Chris

--Lnsp2IoRaSbaVT9J
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (FreeBSD)

iQIcBAEBAgAGBQJSE9WNAAoJEJDCuSvBvK1B5uEP/ilAwzY+WcmBCFy8O60cI0r2
BixA9uatw5XaW86SXOAg4OVIlSoMZILVBMrOc0ibQh8FR6t/XOzcnjk100QCOjJz
CwW/2/SP1rkRLERb+rvRZgmx/C87JCGLpM7H/ch0oqvH3tYsdeaYnjJLnoEAwT5p
xeNLd4YZRnr0HCfa0Wqh/lvoWnbWJurHYmjxCNyFp41NfketT8mf+ZTmIceOK+M9
LjPsAlG/8rHBkNGN5/q1BxUEed3iKFcgfDV67vkJcDK9yL1CBrN53qnfHh4LxLlK
LCij2fLrjWF2qOM+Awtdv5G3NkVoMCayuBirONzmekpmQlr84emr4UyNko81sQDb
uU4VioaVTxHBJnYgBar33yju5bp77Zo10uZf9mMNisfrSaPy58hJPNFlnXOEkteY
EDtFZH4LA1dfzSWEjcqAe75Ku3nMelJ2g2h7nUkHvdA9sYv61TO3JSLd7fhFpTPo
LB073tSeBm6uSFGHzg7GT3KDTQtkbcfnDjEJgKeNW/oNCmmby2W4XMp06RqTTY9T
hWafx4eKNqQvgvhRY7r4EAU3dGnSXk6YgTQ/hiofeR4sEMtM371hNC80PfAQ4ckA
ScXxYG8L+i23DhTS6v3IqUPPiYamM1AMv7d5yoINQwi7ruE7felKGqg01SvsVBPp
sm23SSyQGIX+uikcrhR+
=xJFA
-----END PGP SIGNATURE-----

--Lnsp2IoRaSbaVT9J--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130820204606.GQ4972>