[nycbug-talk] my sysctl quest

[Matthew Story]

On Tue, Mar 13, 2012 at 9:08 PM, Isaac Levy <ike at blackskyresearch.net>wrote:

> Hi Jason,
>
> Sorry this took me time to get back to, but your comments are more than
> welcome- they got me going in the right direction faster:
>
> On Feb 29, 2012, at 12:21 AM, Jason Hellenthal wrote:
>
> >
> >
> > On Tue, Feb 28, 2012 at 04:57:35PM -0500, Isaac Levy wrote:
> >> Hi All,
> >>
> >
> > Hi.
> >
> >> In the spirit of the dmesg db, I need your sysctls!
> >>
> >> Off-list, just send me the output from:
> >> # sysctl -oa ; echo '--' ; dmesg
> >>
> >> Or, if your host has local mail facility:
> >> # echo "`sysctl -oa ; echo '--' ; dmesg`" | mail -s "ike sysctl quest"
> ike at blackskyresearch.net
> >>
> >
> > This is a nice idea and all and dont get me wrong, I am not against it,
> > but it would seem more beneficial in creating a structured SYSCTL_DESC
> > which would help in narrowing down what is already there and what is not
> > allowing to focus on given areas of interest. There might already be a
> > way to scope through the code for empty values of where the descriptions
> > have been left out but I just don't know about it.
> >
> > Speaking purely of FreeBSD and sysctl(9):
> > grep -n SYSCTL_ /usr/src/sys/*/*
>
> Running from FreeBSD svn checkout r232948:
>
> # grep -niR SYSCTL_ ./src/* | wc -l
>   11795
>
> # grep -niR SYSCTL ./src/* | wc -l
>   18507
>
> >
> > grasp the line numbers and file for further processing and the +- some
> > lines to grab extra context should get you pretty close to what needs to
> > be done.
> >
> > static int sysctl_vm_phys_free(SYSCTL_HANDLER_ARGS);
> > SYSCTL_OID(_vm, OID_AUTO, phys_free, CTLTYPE_STRING | CTLFLAG_RD,
> >    NULL, 0, sysctl_vm_phys_free, "A", "Phys Free Info");
>
> SYSCTL_OID seems key to programatically generating documentation from a
> tool,
>
> # grep -niR SYSCTL_OID ./* | wc -l
>     489
>
> Based on your notes, I'm sortof following your approach here- the sysctl
> man pages in section 9 and section 3 both have a ton of info for how I can
> programatically get all all the mib info, so now I'm off to reasonably
> parsing the C source with shell utils to get what I need out of it.
>
>
> >
> >
> > Don't forget about "options NO_SYSCTL_DESCR" which would effectively
> > wipe all these out in a running kernel.
>
> # grep -niR NO_SYSCTL_DESCR ./src/* | wc -l
>      10
>
> Fascinating.  Not in any of the man pages either?  Hrm...
>
> >
> >
> > Anyway after all this these MiBs should be able to be enumerated in a
> > fashion that would yield better results than just recieving random
> > compilations from different systems. Just my opninion.
>
> Your opinion is quite valued here- this is the way I'm headed with this
> now…  I think I can even get all the acceptable values documented in an
> automated fashion from this- (e.g. will kern.foo it take '1m' as arg, or
> only '8388608' [bits]?  Is it bootonly (loader.conf) or runtime
> configurable (sysctl.conf)?)
> I'll see as I go along here- any thoughts welcome.
>
> I'll certainly report back with what comes of it next!
>
> Best,
> .ike
>

You should also (if you haven't already) give sysctl.h a quick read through
(this probably showed up in your grep output):

/usr/src/sys/sys/sysctl.h

Godspeed!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nycbug.org/pipermail/talk/attachments/20120314/91324159/attachment.html>