Message-ID: <3AE77560.1202CF95@kegel.com>
Date: Wed, 25 Apr 2001 18:09:52 -0700
From: Dan Kegel <dank@kegel.com>
MIME-Version: 1.0
To: hahn@coffee.psychology.mcmaster.ca,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: /proc format (was Device Registry (DevReg) Patch 0.2.0)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

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. 

Agreed.

> [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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/