/proc format (was Device Registry (DevReg) Patch 0.2.0)
Quoted 9 lines · Mark Hahn
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.
Agreed.
Quoted 6 lines
[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 generator.
(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