From owner-freebsd-hackers  Thu Dec 28 14:21:38 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id OAA04443
          for hackers-outgoing; Thu, 28 Dec 1995 14:21:38 -0800 (PST)
Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA04423
          for <freebsd-hackers@FreeBSD.ORG>; Thu, 28 Dec 1995 14:21:24 -0800 (PST)
Received: from sa.erisoft.se (epls01.sa.erisoft.se [150.132.128.1]) by mailgate.ericsson.se (8.6.11/1.0) with SMTP id XAA06419; Thu, 28 Dec 1995 23:21:20 +0100
Received: from sws021.sa.erisoft.se by sa.erisoft.se (4.1/SMI-4.1-ERIS0.99)
	id AA06990; Thu, 28 Dec 95 23:21:20 +0100
From: Mattias.Gronlund@sa.erisoft.se (Mattias Gronlund)
Received: by sws021.sa.erisoft.se (5.x/client-1.3)
	id AA05120; Thu, 28 Dec 1995 23:20:46 +0100
Message-Id: <9512282220.AA05120@sws021.sa.erisoft.se>
Subject: Re: sysctl interface
To: phk@critter.tfs.com (Poul-Henning Kamp)
Date: Thu, 28 Dec 1995 23:20:45 +0100 (MET)
Cc: freebsd-hackers@FreeBSD.ORG
In-Reply-To: <16605.820180543@critter.tfs.com> from "Poul-Henning Kamp" at Dec 28, 95 08:55:43 pm
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk

> Well, essential or not, we can argue about.  hw.devconf is what I
> consider "closed territory" and therefore these functions shouldn't
> try to mess with it.  There exists special programs which are good
> at handling that area.  These functions really of any value only for
> the variables that sysctl(8) handles.

Good point, when I think about it i realize what you mean, why should
a user that run "sysctl -a" have to see every little variable that the
kernel exports with the sysctl call, in cases like this there certainly
would be better to have a dedicated tool to parse the data.

> The entire sysctl area is still being reconsidered and rearchitected
> quite a bit, and this particular interface should >>>NOT<<< be relied
> on for the future.

But if I whant to create an interface for iostat to retrive data from
the disk drivers to generate an extended disk statistic, should I wait
untill the interface is "reconsidered and rearchitected" or will
it be a minor thing to convert from the current interface to the uppcoming
interface?

/Mattias