Date: Wed, 30 May 2018 00:16:38 +0000 From: Brooks Davis <brooks@freebsd.org> To: Gleb Popov <arrowd@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Rationale for setting COMMLEN to 19 in struct kinfo_proc Message-ID: <20180530001638.GN99063@spindle.one-eyed-alien.net> In-Reply-To: <CALH631=XtWUMZnrz8%2BOH57GgY07pDY2du9OEOna6Pcd-zF=S8Q@mail.gmail.com> References: <CALH631=XtWUMZnrz8%2BOH57GgY07pDY2du9OEOna6Pcd-zF=S8Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--vbzKE9fGfpHIBC6T
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, May 29, 2018 at 11:42:47PM +0300, Gleb Popov wrote:
> Hello.
>=20
> I've been debugging a failing Qt (KDE, to be precise) test and found that
> process name returned in kinfo_proc structure gets truncated to 19 symbol=
s.
> This causes other errors in the application. I'm wondering why is this
> field so small and is there possibility to increase it? I think, having
> applications with names longer than 19 characters is not that rare.
>=20
> Relevant header: /usr/include/sys/user.h
>=20
> Simple testcase to feature the problem:
>=20
> # cat k.cpp
> #include <sys/types.h>
> #include <signal.h>
> #include <unistd.h>
> #include <stdio.h>
>=20
> #include <sys/cdefs.h>
> #include <sys/param.h>
> #include <sys/sysctl.h>
> #include <sys/user.h>
>=20
> int main()
> {
> auto pid =3D getpid();
> struct kinfo_proc kp;
> int mib[4] =3D { CTL_KERN, KERN_PROC, KERN_PROC_PID, (int)pid };
>=20
> size_t len =3D sizeof(kp);
> u_int mib_len =3D sizeof(mib)/sizeof(u_int);
>=20
> if (sysctl(mib, mib_len, &kp, &len, NULL, 0) < 0)
> return -1;
>=20
> puts(kp.ki_tdname);
> puts(kp.ki_comm);
>=20
> return 0;
> }
> # c++ -o abcdefghijklmnopqrstuvwxyz
> # ./abcdefghijklmnopqrstuvwxyz
> abcdefghijklmnop
> abcdefghijklmnopqrs
Changing the size of fields in kinfo_proc would be enormously
disruptive. Take a look at all the source that uses KERN_PROC_PID for a
subset of things that would break.
Sometimes we can break these interfaces, but I think this one would
require new sysctl mibs. If we did that we should come up with an
interface that is identical between 32-bit and 32-bit systems and
doesn't export pointers.
-- Brooks
--vbzKE9fGfpHIBC6T
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJbDe1lAAoJEKzQXbSebgfAvp0H/2e09ofL4ZQyHkzbnnskb54V
Aghoi0n6oDRBXdxgq9Tza1rXXfq57wGj/Zperb0H9GO3BJzQW9Hbx8FPPWfO42vP
WJJYc+IhJ3ikLE18+XprUdVOlOiNBbW57qx5dnQ6WtsVBBFBdxgKq3fe/3ocOKNQ
0lE61pfhx01pwj5KGNtVQOKRqUF4DwTbCj2+PLCPlguXQ1rlVHv62i/4W24JpG7F
EDvoHJ6DZ/N/yePBPA1b1P/VVbDoWxIpti934cqZhGpZd+jF1fDK9AfbGUNA2Adq
72pWZhirWL1nnFEkZVvNoKIYVEMaY+WPJ6nTCb5VWDQfm8lmf+qFhKcUjrGN5Y0=
=s08Z
-----END PGP SIGNATURE-----
--vbzKE9fGfpHIBC6T--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180530001638.GN99063>