On Mon, Jun 25, 2012 at 8:13 PM, Garrett Cooper <yanegomi_at_gmail.com> wrote: > On Mon, Jun 25, 2012 at 5:03 PM, Arnaud Lacombe <lacombar_at_gmail.com> wrote: >> Hi folks, >> >> I find myself in a situation where I need to directly explore the >> sysctl(8) tree from my program. The tricky part is this: >> >> from `src/sbin/sysctl.c': >> /* >> * These functions uses a presently undocumented interface to the kernel >> * to walk the tree and get the type so it can print the value. >> * This interface is under work and consideration, and should probably >> * be killed with a big axe by the first person who can find the time. >> * (be aware though, that the proper interface isn't as obvious as it >> * may seem, there are various conflicting requirements. >> */ >> >> AFAIT, the whole interface used by sysctl(8) to explore the sysctl >> tree (ie. list, name, get description) is undocumented. This comment >> has been there for about, well... 17 years. No matter to say that it >> is highly unlikely anyone is ever gonna design that perfect interface. >> Right now, I am left with no choice but to figure out how that stuff >> work, which I foresee will be a real PITA. No choice ? Well, not so >> much. About 12 years ago a filesystem interface was written for >> sysctl, namely scfs(4). It was authored by Kelly Yancey and (?) Boris >> Popov. Unfortunately, time passed and no code is any longer publicly >> available. URLs are either no longer valid or password-protected. >> >> This interface would just be perfect for my use-case. No need to spend >> time decoding a prehistoric interface, no need to craft custom >> accessors. I would just have to use standard POSIX file interface... >> if the code was available. >> >> I was hoping some of the people on this list would either, have the >> scfs(4) code on their drives/tapes, or have a way to contact the >> original author(s) and thus have a chance to get that code ? >> >> Thanks in advance, >> - Arnaud >> >> ps: I know the code will certainly have to be fixed, but that is still >> the best option I've got so far. > > Alternatively, the interface could just be documented (from > sys/kern/kern_sysctl.c): > > /* > * "Staff-functions" > * > * These functions implement a presently undocumented interface > * used by the sysctl program to walk the tree, and get the type > * so it can print the value. > * This interface is under work and consideration, and should probably > * be killed with a big axe by the first person who can find the time. > * (be aware though, that the proper interface isn't as obvious as it > * may seem, there are various conflicting requirements. > * > * {0,0} printf the entire MIB-tree. > * {0,1,...} return the name of the "..." OID. > * {0,2,...} return the next OID. > * {0,3} return the OID of the name in "new" > * {0,4,...} return the kind & format info for the "..." OID. > * {0,5,...} return the description the "..." OID. > */ > > I know 2 closed-source versions that have wholesale stolen/"borrowed" > the code from sysctl(3), and I adapted the sysctl(8) code for my own > uses for the cython derivative I made here [1]. > I guess I will have no choice but to write a third... - Arnaud > Thanks, > -Garrett > > 1. http://sourceforge.net/projects/sysctl/Received on Mon Jun 25 2012 - 23:24:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:28 UTC