Date: Thu, 28 Mar 2002 19:52:18 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: hiten@uk.FreeBSD.org, <current@FreeBSD.ORG>, <bug-followup@FreeBSD.ORG> Subject: Re: Some info on the kgmon(8) manual page (regarding current) needed Message-ID: <20020328191029.R7101-100000@gamplex.bde.org> In-Reply-To: <Pine.NEB.3.96L.1020327220033.1932g-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Mar 2002, Robert Watson wrote:
> 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
The getbootfile() call is also wrong. The default for kvm_openfiles()
(which happens to be getbootfile()) should be used. Then kgmon would
know nothing about the details of where the kernel is, and shouldn't
document them. Only kvm really knows where the kernel is. More
important programs like fstat, ps (!) and pstat already use the default
for kvm_openfiles() and know nothing about the details except for
misdocumenting them by saying that the default is /kernel.
This was discussed when getbootfile() was implemented in 1994.
Documenting the details was considered to be too unwieldy. Many
utilities that access the kernel use other parts of kvm ("-M core" and
"-N system" are basically the user interface to kvm_openfiles()) without
documenting exactly how kvm implements these or even referencing
kvm_openfiles(3).
A closer look shows that kvm_openfiles(3) and its getbootfile() call are
now almost irrelevant too. Normally the kernel is live and symbols are
obtained using kldsym(2) (see kvm_nlist(3)); the "-N system" arg and
the result of getbootfile() are essentially ignored in this case.
Liveness is determined by the "-M core" arg. The default corefile is
/dev/kmem, and using this or any other device file gives a "live" kernel.
The name of the kernel becomes relevant when the output of kgmon is used.
gprof doesn't know anything about kernels, so it needs a normal executable
file with symbols. kgmon provides no hints about its name. I always
invoke gprof on kernels using:
gprof -u `sysctl -n kern.bootfile` gmon.out
(kgmon has not been converted to produce <prog>.gmon instead of gmon.out,
so you have to tell gprof the name of the gmon file too. If kgmon generated
<prog>.gmon, then it would actually need to know the name of the kernel.)
> 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.
It is supposed to be fairly reliable. syslogd() still depends on it to
supply the kernel name which it prepends to every line of log files, and
I don't remember a single report about this name being wrong :-).
Bruce
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?20020328191029.R7101-100000>