From owner-freebsd-commit  Tue Nov  7 08:52:30 1995
Return-Path: owner-commit
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id IAA25131
          for freebsd-commit-outgoing; Tue, 7 Nov 1995 08:52:30 -0800
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id IAA25115
          for cvs-all-outgoing; Tue, 7 Nov 1995 08:52:21 -0800
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id IAA25104
          for cvs-sys-outgoing; Tue, 7 Nov 1995 08:52:16 -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 IAA25094
          ; Tue, 7 Nov 1995 08:52:01 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA10078; Wed, 8 Nov 1995 03:48:02 +1100
Date: Wed, 8 Nov 1995 03:48:02 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199511071648.DAA10078@godzilla.zeta.org.au>
To: peter@jhome.dialix.com, phk@freefall.freebsd.org
Subject: Re: cvs commit: src/sys/kern kern_sysctl.c
Cc: CVS-commiters@freefall.freebsd.org, cvs-sys@freefall.freebsd.org
Sender: owner-commit@FreeBSD.org
Precedence: bulk

>Umm, I've not been following your sysctl() work closely, and indeed I'm 
>not too fresh on sysctl in general these days, but does sysctl(8) 
>automatically adapt to new entries being added into the kernel?

No.  You have to edit 2 or 3 kernel files, 1 or 2 man pages, and
sometimes the sysctl(8) for each new entry.

>It's all done with linker_sets, right?  Is there any chance of getting 
>the system to automatically catalog all the sysctl's?  for example, 

I think linker sets are the wrong approach.  There's no way a linker
set in the kernel can update the manpage or specially handle a new
struct in sysctl(8).  I'd like either a static or dynamic central
catalog.  The static version would involve a text file that you edit
and run utilities on to produce man pages, kernel and user code.  The
dynamic version would involve a text file that you edit and run to
produce only kernel code, and more general handling of structs in
sysctl(8), and a more general man page that doesn't mention any
particular variable.

The sysctl interface uses a fixed binding of names to numbers.  I
think there should be a separate binding step.  E.g.,

	/* Interface: return a `name' suitable for passing to sysctl(8). */
	int sysctl_bind(const char *varname, u_int max_namelen, int *name,
			u_int *namelen);

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

	/*
	 * Interface: return a sysctl descriptor suitable for passing to
	 * new_sysctl(8).  Indirectly return the names (possibly null;
	 * concatenated) of each component of each variable, and layout
	 * information (perhaps the number of components for each variable).
	 */
	int sysctl_bind(const char * const *varnames, u_int nvarnames,
			char *varsubnames, u_int *varlayoutinfo);
	/*
	 * Interface: like sysctl(3) except the variables of interest are
	 * determined by a previous sysctl_bind() and the data is an array
	 * of u_longs packed according to the layout info (perhaps not
	 * packed at all, i.e., with all scalars expanded to u_longs).
	 */
	int new_sysctl(int sd, u_long *oldp, u_int *oldlenp, u_long *newp,
		       u_int newlen);

Bruce