Messages in this thread | | | Date | Thu, 17 Apr 1997 09:09:03 -0400 | From | James Hughes <> | Subject | Re: procfs problems |
| |
Todd Graham Lewis wrote: > > On Wed, 16 Apr 1997, James Hughes wrote: > > > How about using ASN to define a MIB for the values in the procfs and get > > an enterprise number registered for Linux with the INA? The values can > > be read by humans as now in human friendly strings or in OID format > > depending on the method of retrieval. > > I don't like this idea because I've been mulling it for a few days. 8^) >
Yeah, I've seen this same thread in various forms for a year or so now. I've mentioned this every time and then the list gets purged, so beware :)
> I do like this idea because it's a really good one. Also, n.b. that /proc > has tons of overlap with MIB-II variables already, and MIB-II could offer > some suggestions as to which information might be useful in /proc. > > "Me too." >
One advantage of such a scheme is that it would be well documented. It would be easy for driver/subsystem developers to impliment the reporting and control functionality in their code and be consistant with the rest of the system. The experimental tree can be used for "under-development" items. When they're officially integrated into the kernel, they could be moved under the Linux enterprise tree.
I've seen references to the "sysctl" system. I think this would be the place to hook all this in. It could report values, update counters, schedule SetOID jobs (which could be used to adjust driver/subsystem parameters, etc.).
The Linux version of the CMU-SNMP agent could drive the procfs via "sysctl". The procfs could be made to also respond to 'echo value > /proc/item' and 'cat /proc/item', as it is now.
The interface would be there for all kinds of local 'system control' or 'configuration' utilities to use. So it would help those who don't use networking as well.
> Incidentally, I offered the snmpd developers to register a Linux MIB, but > they were of the opinion that it'd be too much of a political football. I > think that Linux International might make a decent custodian, but I really > don't see too many Linux-specific variables that we'd need. There's > already a Linux-specific tree off of utwente's EOID, so that could be used > as well. (Hell, we could delegate a tree off of Mindspring's EOID; > namespace under snmp isn't that hard to come by.) >
Even though the mgmt OID is pretty comprehensive, I think we should have our own EOID. It just makes a statement about Linux. Besides, it would give us a place to generate those "lp1 on fire' messages ;)
I think Linux International would be a good candidate to officiate the Linux tree. Whoever does would need to delve out the proper OID's when each driver/subsystem comes out of development. So, they would probably need volunteers to help with that.
> The ASN.1 part is a really great idea, though. I could help write the MIB > if anyone thinks it's any good. >
What if each driver/subsystem comes with the fields in the header files. When we 'make config' we select the drivers we want included in the build. When we 'make dep' the MIB for our configuration is made automatically from the information in the selected drivers/subsystem headers. Could we do that? I saw a "Linux Drivers Developers Kit" once. Could somthing like that make it easy for the developer to coordinate the OID/sysctl/MIB with their code?
That way the MIB, therefore the procfs and sysctl interface, is updated with current information automaticaly each time a new kernel is built instead of one person having to keep up with all new or obsolete components in the system. The load of maintaining the procfs would be distributed among the developers. And they would be able to use the power of the system to enhance the functionality of their code.
-James
--
This 'telephone' has too many shortcomings to be seriously considered as a means of communication. The device is inherently of no value to us. -- Western Union internal memo, 1876.
| |