Date: Wed, 27 Mar 2002 22:05:58 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: hiten@uk.FreeBSD.org Cc: current@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: Some info on the kgmon(8) manual page (regarding current) needed Message-ID: <Pine.NEB.3.96L.1020327220033.1932g-100000@fledge.watson.org> In-Reply-To: <20020328004410.9310.qmail@web21102.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Mar 2002, Hiten Pandya wrote: > According to me, the utility shouldn't be using a hardcoded path to the > booting kernel, as this would affect kernels which were made by: > > makeoptions KERNEL=foo #Build kernel "foo" and install "/foo" > > What are your suggestions? The utility doesn't appear to have any hard-coded paths in it at all. It gets them from one of two places: getbootfile(), or the command line. If getbootfile() is used then it's right. If you specify it on the command line and that's wrong, it's your fault. It's worth noting, as I did to Garance out-of-band, that the path returned by getbootfile() may be wrong for a variety of reasons, including: - The kernel at that path has been replaced for some or another reason, including kernel upgrade. - The file system root doesn't match that used by the boot loader, either because chroot() has occurred for the current process, or because the root and boot devices differ (e.g., network load of kernel, local root file system). getbootfile() is relatively unreliable, as such, but is a decent default. > In any case, I will take the precautions which Giorgos has put in place, > and will produce the patches accordingly. :) I'd avoid your later changes involving describing how getbootfile() relies on sysctl in the kgmon(8) man page. That's an implementation detail of the API, not of kgmon, and while it probably won't change, putting the information there increases the chances of it getting stale, as well as exposing system MIB information that has a well-documented API for accessing it. Talking about the possible failure modes of the call probably is relevant, since that impacts correct functionality of kgmon(8). Giorgos' patch, modulo reference to -N, is probably the right answer. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020327220033.1932g-100000>