Subject: Re: sysctl vs. virtual filesystems.
To: NetBSD Kernel Technical Discussion List <tech-kern@netbsd.org>
From: Greywolf <greywolf@starwolf.com>
List: tech-kern
Date: 06/21/2002 15:23:48
Or we could throw them both out and go back to the dark ages completely
instead of doing a half-assed job by eliminating only one of them.

They're both useful, depending on your point of view.  If /proc goes
away, you need kmem grovelers for process information.  If sysctl goes
away, how do you propose to do what sysctl handles now, do you propose
we put it into a /sysctl place?  or /ctl/sysctl?  (I'll get to this
in a moment.)

Upon a moment's reflection, this doesn't look like an all-bad idea.
It all depends on the interface one wants.  I will say that sysctl
(and its ilk) do a better job of making the information immediately
available (rather than having to do a 'find /ctl/sysctl ! -type d |
(while read x; do printf "%s = " $x; cat $x; done)', you only need to
say 'sysctl -a').  But having a /ctl/*ctl would be at least interesting.
One would only need to look at the contents of /ctl to see what was
present to be controlled (/ctl/audioctl wouldn't be present, i.e. if
there was no audio device hooked up).

Never mind the problem with multiple interfaces/devices, that's an
issue of semantics that can always be hammered out later.

But if the virtual fs approach is taken, I think it would be a good
idea to make a central '/control' or similar point which would handle,
as subtrees, more than just the equivalent of "sysctl".  We have quite
a few *ctl utilities around.  I think it would be nice if we could
consolidate them.


On Fri, 21 Jun 2002, Greg A. Woods wrote:

# Date: Fri, 21 Jun 2002 15:55:24 -0400 (EDT)
# From: Greg A. Woods <woods@weird.com>
# Reply-To: NetBSD Kernel Technical Discussion List <tech-kern@netbsd.org>
# To: tech-kern@netbsd.org
# Subject: Re: sysctl vs. virtual filesystems.
#
# [ On Friday, June 21, 2002 at 10:27:31 (+0200), Jaromir Dolecek wrote: ]
# > Subject: Re: Time to bump the default open files limit?
# >
# > I don't particularily like any further enhancements to /proc. /proc
# > is hack which should die painful death.
#
# Personally I think using sysctl for anything but reading and setting a
# few simple system-wide integers, and maybe the odd string, is a horrible
# hack which should die a painful death.  I have far more tools at my
# disposal for dealing with things using the filesystem metaphor than I do
# for using such ugly hacks as sysctl.
#
# (Of course I'm not saying the current implementation of /proc is ideal
# -- it does leave something to be desired in some places)
#
# --
# 								Greg A. Woods
#
# +1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
# Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>
#


				--*greywolf;
--
NetBSD: u_long uptime;