/proc objtree summary

Clayton Weaver (cgweav@eskimo.com)
Mon, 2 Nov 1998 04:12:54 -0800 (PST)


Finally: the one good reason to implement an object tree foundation for
/proc is because it decouples the numeric data values from the character
strings in human-readable /proc files. To get a data value, a user-space
program doesn't need to know what string describes that data in a table
or list (no keyword search to find the value needed), and it doesn't need
to know the offset of the data into a file.

The kernel can still convert the numbers to strings and hold them in
memory that way as /proc files if that's more efficient than converting
them on demand when some reads a /proc file, but whether it does or not
doesn't affect software that doesn't use those strings.

That makes it possible for users in other locales to modify the /proc file
strings if they want without affecting anything except the human readable
view of /proc as a filesystem of text files. All that such modification
would affect is terminal display. They get correct values via object index
number no matter where their new strings move the display of those values
around in /proc files.

Footnote: as to why the "not-accessible" attribute in snmp is there, one
can see why one might want that restriction available by thinking about
wildcard lookups. One doesn't want to enable a request like "get me 0",
ie copy all of /proc into a local process context (although I don't see
why retrieving all of ipAddrTable with one get request is so fearsome, but
anyway one can always iterate around it). So restricting wild card index
numbers to leaf node level lookups is probably a reasonable precaution.

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/