Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Jun 1998 13:27:47 -0600
From:      Nate Williams <nate@mt.sri.com>
To:        dyson@FreeBSD.ORG
Cc:        nate@mt.sri.com (Nate Williams), hackers@FreeBSD.ORG
Subject:   Re: kernfs/procfs questions...
Message-ID:  <199806041927.NAA03558@mt.sri.com>
In-Reply-To: <199806041920.OAA02171@dyson.iquest.net>
References:  <199806041910.NAA03447@mt.sri.com> <199806041920.OAA02171@dyson.iquest.net>

next in thread | previous in thread | raw e-mail | index | archive | help
John S. Dyson writes:
> > And, I'm not stating that it's to be taken to the polar extreme either,
> > but that it's a *better* solution than sysctl.  It's still not the best
> > solution either, but extending a poorer solution is certainly a step
> > in the wrong direction.
> > 
> > I agree with Bruce in that programs are generally a better way of
> > configuring things.  It's obvious if you know the system what needs to
> > be run, and how to get help on it.  It also makes documenting things
> > easier, which sysctl does not.  People already hate to document, and
> > making it hard to figure out where/how to document things just makes it
> > that much less likely to be documented.
>
> I disagree for easily one simple reason:  sysctl affords an internal
> documentation scheme that isn't a hack.

Only to a developer, not to a user.  Here's some of your log messages
for sysctl's that mean something to you, but don't mean a thing to a
normal user.

vm_param.h
vm.pageout_algorithm=????

vm_zone.c
Add exposure of some vm_zone allocation stats by sysctl.

And these would be, and would help me by?  Where should they be
documented for the user?  man 9 tuning?  Are they specific to the zone
allocation?

I'm not saying that kernfs would make this easier, but if I had a tuning
program that allowed me to tune it (man 8 vmtune), then it would be
*better* documented.  Maybe I'm not screaming so much for the
implementation, but the interface and the way that new sysctl are added
w/out any regard to documentation/accessing them. :(




Nate


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806041927.NAA03558>