An snmp MIB is an object tree, which is a reasonably efficient structure
to search. It has a structure comparable to a filesystem, and instead
of passing /path/sub/sub/sub/file to get data, you pass numbers that index
the tree at each level down to the data that you want:
1.13.2.4.1.2.4...
This is a reasonably fast structure for a server to lookup. If it's on
disk, the server just mmap()s it. If it's in-core, you walk it like
any other unbalanced tree.
The prerequisite is object definitions for /proc data. The BER rules
preface each data value with a data type code, which combines
primitive/constructed, public/private, etc, and fits in 8 bits, then
follows that with a length value, then the data.
Perhaps we don't need that, or at least not universally. I.e., we could
use ASN.1 like object definitions as the basis for agreement on data types
in the object tree and how to index them, but just store the data at the
positions in the tree implied by the "Linux /proc MIB" without the type
code in there (since /proc generating code and /proc-using code both have
access to the "MIB" definition). You could keep the length (I'm thinking
for string data and integral types that could be 4 or 8 bytes, depending
on the local hardware, kernel version, glibc version, etc) bytes before
any given data item. It seems wasteful for 32-bit ints, longs, and all of
their abstract data type aliases, but without that, someone's software is
going to get confused somewhere on whether a particular long is 4 or 8
bytes.
Standard snmp practice argues against not keeping the data type identifier
and length before the data on the basis that this loses abstraction and
requires recompiling the world when someone adds a couple of bytes to a
fixed length octet string that describes some parameter. But how many of
these tools used fixed size buffers and expect the data to fit into a
certain number of characters on a tty? These tools are going to have to
update their code anyway if you add two bytes to an octet string, unless
they have page layout engines in their admin tools (yeah right). What
do you do with the two bytes if you haven't seem them before? What do
they mean? The only way to find out is on the mailing list.
Anyway, an object tree like that, with just the data at the tree nodes
that the MIB-workalike specifies, should be implementable. The structure
of it is static at boot time, except for the length and content of strings
like those in /proc/cmdline and the actual data values of object nodes
that the kernel updates dynamically. /proc/binary/ only needs two files,
/proc/binary/meta (for endianness and version) and /proc/binary/objtree.
You can still generate the traditional /proc files via lookup into the
object tree and tools that only need the binary values can index into
the tree instead of parsing the human-readable files and doing strtoul()
to get their data.
This seems to me a more workable solution than trying to shadow every
file in /proc with another file that holds only the binary values, plus
telling admin tools and the display_files part of /proc how to fit strings
to the data, especially when some of the data varies not only in length
but in how many discrete numeric data values there are in a particular
"record".
If /proc/syscfg is implemented, it should just fit into the object tree
and callback for display and update. This blows away making /proc/binary/
read-only, ie an immutable filesystem, so the objtree filesystem just
has to know which values are writable and which aren't. Probably keep
an internal tree that indexes writable nodes, so it can look up
whether a node is modifiable if someone tries to write to it.
It's still a schema, it's just tree-structured, similar to nested
relational. The strings that the display_traditional_procfile callback
uses can be in the objtree, too, for convenience and locality. If anyone
changes the length or native language of them, they're going to have to
hack the admin tools too, or the stuff won't display sanely on a 25x80
terminal. But that won't affect programs ignoring the strings and just
indexing the binary data. The strings have different numbers than the
numeric values, they are different leaves at a node. Top won't have to
do strtoul() to get it's data, for example.
That's my idea. It shouldn't be all that tough for an snmp server to get
what it needs from /proc if we can provide them with an ASN.1 objtree
description of it, and tell them that they already have to know what
the data types are.
Regards, Clayton Weaver <mailto:cgweav@eskimo.com> (Seattle)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/