Subject: Re: sysctl vs. virtual filesystems.
To: NetBSD Kernel Technical Discussion List <tech-kern@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-kern
Date: 06/21/2002 20:15:39
[ On Friday, June 21, 2002 at 15:23:48 (-0700), Greywolf wrote: ]
> Subject: Re: sysctl vs. virtual filesystems.
>
> 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.)

I didn't propose that sysctl go away (though indeed it could be easily
replaced by a virtual filesystem, even while at the same time keeping
the current command-line interface).

What I said, essentially, was only that sysctl should not be used for
accessing internal state (tables and such, stuff which is much more
commonly accessed and which can be better manipulated by tools already
available for dealing with simple text-form data).  I suppose even
proc.<pid>.rlimit isn't so bad, though as the manual page currently
admits even it has "special semantics", and it's that need to describe
its semantics as special which raises red flags and suggests that maybe
this isn't the right interface to use for this purpose.

Think about how you access files, and how many new and useful ways you
might be able to deal with the output of all the kernel grovellers, such
asnetstat/fstat/ps/etc., if you could access it in a logical way through
a filesystem interface -- i.e. as if the data were just stored in a file.

Sysctl is a fine interface for reading and setting a few system-wide
control knobs, and even for reading various simple non-tabular counters
that you don't have to look at very often -- i.e. things that sysadmins
do on occasion.  (Though there are problems with the implementation of
sysctl, particularly inside the kernel -- it's not nearly as flexible as
it could be.)  Perhaps a "/sysctl" virtual filesystem would be a nifty
enhancement though....  (i.e. have both!)

That all said I must admit there seem to have been (far?) fewer nasty
bugs introduced via sysctl() than have ever been introduced by various
virtual filesystem implementations.....  I don't know what that means
though.

-- 
								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>