From bde@zeta.org.au  Thu Mar 28 00:51:52 2002
Return-Path: <bde@zeta.org.au>
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6811937B41D; Thu, 28 Mar 2002 00:51:47 -0800 (PST)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA23503;
	Thu, 28 Mar 2002 19:51:43 +1100
Message-Id: <20020328191029.R7101-100000@gamplex.bde.org>
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>
In-Reply-To: <Pine.NEB.3.96L.1020327220033.1932g-100000@fledge.watson.org>
Subject: Re: Some info on the kgmon(8) manual page (regarding current) needed

>Number:         36414
>Category:       docs
>Synopsis:       Re: Some info on the kgmon(8) manual page (regarding current) needed
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 28 01:00:02 PST 2002
>Closed-Date:    Thu Mar 28 16:38:33 PST 2002
>Last-Modified:  Wed Oct 26 05:01:48 GMT 2005
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
 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
 
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: keramida 
State-Changed-When: Thu Mar 28 16:36:27 PST 2002 
State-Changed-Why:  
Followup to email misfiled as a PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=36405 
State-Changed-From-To: open->closed 
State-Changed-By: keramida 
State-Changed-When: Thu Mar 28 16:36:27 PST 2002 
State-Changed-Why:  
Followup to email misfiled as a PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=36406 
State-Changed-From-To: open->closed 
State-Changed-By: keramida 
State-Changed-When: Thu Mar 28 16:36:27 PST 2002 
State-Changed-Why:  
Followup to email misfiled as a PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=36414 
>Unformatted:
