Re: procfs problems

James Hughes (
Thu, 17 Apr 1997 09:09:03 -0400

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.



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.