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. Itwould be easy for driver/subsystem developers to impliment the reportingand control functionality in their code and be consistant with the restof the system. The experimental tree can be used for "under-development"items. When they're officially integrated into the kernel, they could bemoved under the Linux enterprise tree.

I've seen references to the "sysctl" system. I think this would be theplace to hook all this in. It could report values, update counters,schedule SetOID jobs (which could be used to adjust driver/subsystemparameters, 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 usenetworking 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 haveour own EOID. It just makes a statement about Linux. Besides, it wouldgive us a place to generate those "lp1 on fire' messages ;)

I think Linux International would be a good candidate to officiate theLinux tree. Whoever does would need to delve out the proper OID's wheneach driver/subsystem comes out of development. So, they would probablyneed 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 thebuild. When we 'make dep' the MIB for our configuration is madeautomatically from the information in the selected drivers/subsystemheaders. Could we do that? I saw a "Linux Drivers Developers Kit" once.Could somthing like that make it easy for the developer to coordinatethe OID/sysctl/MIB with their code?

That way the MIB, therefore the procfs and sysctl interface, is updatedwith current information automaticaly each time a new kernel is builtinstead of one person having to keep up with all new or obsoletecomponents in the system. The load of maintaining the procfs would bedistributed among the developers. And they would be able to use thepower of the system to enhance the functionality of their code.

-James

--

This 'telephone' has too many shortcomings to be seriously consideredas a means of communication. The device is inherently of no value tous. -- Western Union internal memo, 1876.