Content-Type: text/plain; charset=US-ASCII
From: Tim Jansen <tim@tjansen.de>
To: Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.5 PROPOSAL: Replacement for current /proc of shit.
Date: Thu, 1 Nov 2001 13:06:00 +0100
In-Reply-To: <E15zF9H-0000NL-00@wagner>
In-Reply-To: <E15zF9H-0000NL-00@wagner>
MIME-Version: 1.0
Content-Transfer-Encoding: 7BIT
Message-ID: <15zGYm-1gibkeC@fmrl05.sul.t-online.com>
Sender: linux-kernel-owner@vger.kernel.org

On Thursday 01 November 2001 11:32, Rusty Russell wrote:
> I believe that rewriting /proc (and /proc/sys should simply die) is a
> better solution than extending the interface, or avoiding it
> altogether by using a new filesystem.

I am currently working on something like this, too. It's using Patrick 
Mochel's driverfs patch 
(http://www.kernel.org/pub/linux/kernel/people/mochel/device/driverfs.diff-1030) 
as a base and adds the functionality of the extensions that I did to proc fs 
for my device registry patch 
(http://www.tjansen.de/devreg/proc_ov-2.4.7.diff). 

You can get an idea of the API in the proc_ov patch: every file in the 
filesystem is typed and either a string, integer, unsigned long or an enum. 
The intention is that you have a single value per file, like in /proc/sys, 
and not more. The API does not even allow you to have more complex files (I 
plan to add a blob type though).  
Unlike comparable APIs it also supports 'dynamic directories'. So you can, 
for example, create a directory for each device without registering a 
directory for each device. You only need a single dynamic directory with a 
couple of callbacks that specify the number of directories, their names and 
their contexts. Contexts are void pointers that are given to the callbacks of 
the content files, in this example you would probably use the pointer to the 
device's struct device as context. 

bye...
 
-
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/