From owner-cvs-sys  Tue Nov  7 09:43:11 1995
Return-Path: owner-cvs-sys
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id JAA26758
          for cvs-sys-outgoing; Tue, 7 Nov 1995 09:43:11 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA26751
          ; Tue, 7 Nov 1995 09:42:58 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id EAA12200; Wed, 8 Nov 1995 04:41:50 +1100
Date: Wed, 8 Nov 1995 04:41:50 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199511071741.EAA12200@godzilla.zeta.org.au>
To: bde@zeta.org.au, wollman@lcs.mit.edu
Subject: Re: cvs commit: src/sys/kern kern_sysctl.c
Cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org,
        peter@jhome.dialix.com, phk@freefall.freebsd.org
Sender: owner-cvs-sys@FreeBSD.org
Precedence: bulk

>> Even better, redesign sysctl() to support accessing an arbitrary subset
>> of the database:

>> [suggested deleted]

>This looks very much to me like using a sledgehammer to pound in a 3d
>finish nail.

It's to support gathering statistics simply and efficiently for utilities
like systat.  After you decide which variables to display on a screen and
format the screen nicely, you build an array of the variables and pass it
to sysctl_bind() to get a descriptor that describes precisely all of the
variables of interest (only if they are supported and and the caller has
enough privilege of course).  The kernel can then gather all the variables
efficiently in a single syscall, and structs can be handled portably by
treating their members as scalars.

systat currently uses sysctl() to read CTL_VM.VM_METER and gropes in kmem
for everything else.  It needs about 60 system calls for every update.

Bruce