Date: Mon, 29 Jun 2015 12:56:18 -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: <CAD44qMWwjY3An0xoOtohnRrAEANsC_gt-i19aj9TSufCtFL75w@mail.gmail.com> In-Reply-To: <CAD44qMUVPH4eY4zBfkBQ_m0Vhxg0M1CM7TXZv9emKjWdV8jTVg@mail.gmail.com> References: <558F1D88.8010407@ignoranthack.me> <CAD44qMUVPH4eY4zBfkBQ_m0Vhxg0M1CM7TXZv9emKjWdV8jTVg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 28, 2015 at 2:26 AM, Patrick Kelsey <pkelsey@freebsd.org> wrote: > > > > 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. > A patch for this is posted for review at https://reviews.freebsd.org/D2945. -Patrick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD44qMWwjY3An0xoOtohnRrAEANsC_gt-i19aj9TSufCtFL75w>