Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S280641AbRKFWts>; Tue, 6 Nov 2001 17:49:48 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S280656AbRKFWta>; Tue, 6 Nov 2001 17:49:30 -0500
Received: from dvmwest.gt.owl.de ([62.52.24.140]:4 "EHLO dvmwest.gt.owl.de")
	by vger.kernel.org with ESMTP id <S280641AbRKFWtN>;
	Tue, 6 Nov 2001 17:49:13 -0500
Date: Tue, 6 Nov 2001 23:49:10 +0100
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-kernel@vger.kernel.org
Subject: Re: PROPOSAL: /proc standards (was dot-proc interface [was: /proc
Message-ID: <20011106234910.C26236@lug-owl.de>
Mail-Followup-To: linux-kernel@vger.kernel.org
In-Reply-To: <slrn9ugh1g.dld.spamtrap@dexter.hensema.xs4all.nl> <Pine.LNX.4.33L.0111061921240.27028-100000@duckman.distro.conectiva> <20011106152826.C31923@codepoet.org> <20011106233349.A26236@lug-owl.de> <20011106154240.A32249@codepoet.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20011106154240.A32249@codepoet.org>
User-Agent: Mutt/1.3.23i
X-Operating-System: Linux mail 2.4.5 
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 2001-11-06 15:42:40 -0700, Erik Andersen <andersen@codepoet.org>
wrote in message <20011106154240.A32249@codepoet.org>:
> On Tue Nov 06, 2001 at 11:33:49PM +0100, Jan-Benedict Glaw wrote:
> > On Tue, 2001-11-06 15:28:26 -0700, Erik Andersen <andersen@codepoet.org>
> > wrote in message <20011106152826.C31923@codepoet.org>:
> > > On Tue Nov 06, 2001 at 07:24:13PM -0200, Rik van Riel wrote:
> > > > PROCESSOR=0
> > > > VENDOR_ID=GenuineIntel
> > 
> > PROCESSOR=1
> > ...
> > 
> > > > . /proc/cpuinfo
> > > 
> > > I think we have a winner!  If we could establish this 
> > > as policy that would be _sweet_!
> > 
> > What do you expect on a SMP system?
> 
> How about something like:
> NUMBER_CPUS=8
> VENDOR_ID_0=GenuineIntel

Well, somebody came up with the idea of having XML in kernel. I'd really
love to see all those single-file-multiple-info files going away. Can't
we have a simple tree using one file per value / one value per file?
Would ease *many* things a lot...

MfG, JBG

-- 
Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481
-
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/