Date: Sun, 28 Jun 2015 02:26:06 -0400 From: Patrick Kelsey <pkelsey@freebsd.org> To: sbruno@freebsd.org Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: sysctl(3) man page examples Message-ID: <CAD44qMUVPH4eY4zBfkBQ_m0Vhxg0M1CM7TXZv9emKjWdV8jTVg@mail.gmail.com> In-Reply-To: <558F1D88.8010407@ignoranthack.me> References: <558F1D88.8010407@ignoranthack.me>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 27, 2015 at 6:02 PM, Sean Bruno <sbruno@ignoranthack.me> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > sysctl(3) specifies three easy to understand examples. > > The first appears to depend on a FreeBSD libc() function or library that > is missing, "printkproc()". Is this a deprecated/deleted function from > the past? > This example was committed in r71409, which was between the 4.2 and 4.3 releases. Today, and at that time, the result of fetching a particular kern.proc.pid is a struct kinfo_proc, not struct kinfo_kproc (which did and does not exist). There appears to never have been a printkproc() function (nor print_kproc(), nor printproc(), nor print_proc()) - this seems to be a function that is assumed to exist elsewhere in the unseen parts of the example program. > > The second example works just fine. > > The third accesss user.cs_path which seems to be empty across all > platforms. I'm not sure if we should replace this example with > something more meaningful(that is to say that its proper for > user.cs_path to be empty) or if there is a bug causing user.cs_path to > be empty. > > This appears to be a bug that was introduced almost three years ago in r240176. sysctl() in lib/libc/gen/sysctl.c has special handling for USER_CS_PATH that returns the value of _PATH_STDPATH, which is "/usr/bin:/bin:/usr/sbin:/sbin". However, this special handling for USER_CS_PATH was short circuited by r240176, which introduced the requirement that __sysctl() return ENOENT in order to reach the special USER_CS_PATH handling. However, __sysctl() doesn't return ENOENT for USER_CS_PATH because there is a sysctl entry for it (containing an empty string) that is created in sys/kern/kern_mib.c, apparently so that user.cs_path exists when enumerating the names in the sysctl tree. -Patrick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD44qMUVPH4eY4zBfkBQ_m0Vhxg0M1CM7TXZv9emKjWdV8jTVg>