[nycbug-talk] my sysctl quest

Isaac Levy ike at blackskyresearch.net
Tue Mar 13 21:08:54 EDT 2012


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




> 
>> 
>> --
>> Why do I want sysctl dumps?!?
>> 
>> Recently, I was reminded of how many times we've discussed sysctl documentation (and the lack thereof).
>> (e.g. commonly, 'is FOO.sysctl in bits or bytes?' 'is that bootonly, or runtime-configurable?' etc...)
>> 
>> Some other people have had this thought too:
>> http://wiki.freebsd.org/IdeasPage#Document_all_sysctls
>> I'm diving into this project.
>> 
>> --
>> Why I want your sysctls?
>> 
>> I'm finding there's particular differences in architectures, hardware drivers, defaults which are different for different hardware resources, etc…
>> I want to get an idea of the possible variance right up front, so, as many sysctl dumps as possible, from as many places as possible.
>> 
>> Again, just send me the output from:
>> # sysctl -oa ; echo '--' ; dmesg
>> 
>> WARNING: you may divulge systems information which you don't want to, if so, don't send the sysctl at all!  (After all, I am just some dude on a list!)
>> Your sysctl info/values could eventually end up in public view, or shared with other developers.  If so I'll do my best to anonomize the data, but if you have sensitive systems info, just don't send it.
>> 
>> --
>> What I want:
>> 
>> I'm focused on FreeBSD, but NetBSD, OpenBSD, DragonFlyBSD, and even dumps from other UNIX'es are quite welcome to me right now.  Jailed systems, Xen/VmWare/Etc instances, AWS systems, whatever.  Running on an obscure architecture? Running legacy systems? Even better!
>> 
>> --
>> Later, I've got thoughts on what to *do* with the sysctl documentation, some way to collect and maintain docs across projects even.
>> Perhaps a big man page will suffice.  Perhaps some utility in the spirit of perror(1) would be more satisfactory.
>> 
>> In the meantime, I want to get a good view of how much variance there actually is in sysctls themselves- and for that, I need data!
>> 
>> Thanks in advance for any sysctls!
>> 
> 
> Good luck on your quest.
> 
> -- 
> ;s =;




More information about the talk mailing list