[lkml]   [2001]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: /proc format (was Device Registry (DevReg) Patch 0.2.0)
Mark Hahn wrote:
> the main goal at this point is to make kernel proc-related
> code more efficient, easy-to-use, etc. a purely secondary goal
> is to make user-space tools more robust, efficient, and simpler.
> there are three things that need to be communicated through the proc
> interface, for each chunk of data: its type, it's name and its value.
> it's critical that data be tagged in some way, since that's the only
> way to permit back-compatibility. that is, a tool looking for a particular
> tag will naturally ignore new data with other tags.


> [three example schemes in use in /proc today]
> I have a sense that all of these could be collapsed into a single
> api where kernel systems would register hierarchies of tuples of
> <type,tag,callback>, where callback would be passed the tag,
> and proc code would take care of "rendering" the data into
> human readable text (default), binary, or even xml.

Sounds reasonable to me. Relieve the modules of having to
format their /proc entries by defining standard code that does
it. And as an extra bonus, if tuples registration was table-driven,
the tables would define a grammar that could be fed to a parser

(It sounds a little bit like the snmpd code I'm working on,
actually. How eerie.)

(It also sounds a little like (gasp) the windows registry,
but hey, that's ok.)

- Dan
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:52    [W:0.025 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site