Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 4 Nov 2001 22:00:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 4 Nov 2001 22:00:04 -0500 Received: from [202.108.68.176] ([202.108.68.176]:58794 "HELO xteamlinux.com.cn") by vger.kernel.org with SMTP id ; Sun, 4 Nov 2001 21:59:54 -0500 Message-ID: <3BE67230.5040006@xteamlinux.com.cn> Date: Mon, 05 Nov 2001 11:04:16 +0000 From: zmwillow User-Agent: Mozilla/5.0 (X11; U; Linux i686; zh-CN; rv:0.9.4) Gecko/20010917 X-Accept-Language: zh, zh-tw, en-us MIME-Version: 1.0 To: Jakob =?ISO-8859-1?Q?=D8stergaard?= CC: linux-kernel-mail-list Subject: Re: PROPOSAL: dot-proc interface [was: /proc stuff] In-Reply-To: <160MMf-1ptGtMC@fmrl05.sul.t-online.com> <20011104143631.B1162@pelks01.extern.uni-tuebingen.de> <160Nyq-2ACgt6C@fmrl07.sul.t-online.com> <20011104163354.C14001@unthought.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jakob ?tergaard wrote: >Here's my stab at the problems - please comment, > >We want to avoid these problems: > 1) It is hard to parse (some) /proc files from userspace > 2) As /proc files change, parsers must be changed in userspace > >Still, we want to keep on offering > 3) Human readable /proc files with some amount of pretty-printing > 4) A /proc fs that can be changed as the kernel needs those changes > > >Taking care of (3) and (4): > >Maintaining the current /proc files is very simple, and it offers the system >administrator a lot of functionality that isn't reasonable to take away now. > > * They should stay in a form close to the current one * > > >Taking care of (1) and (2): > >For each file "f" in /proc, there will be a ".f" file which is a >machine-readable version of "f", with the difference that it may contain extra >information that one may not want to present to the user in "f". > >The dot-proc file is basically a binary encoding of Lisp (or XML), e.g. it is a >list of elements, wherein an element can itself be a list (or a character string, >or a host-native numeric type. Thus, (key,value) pairs and lists thereof are >possible, as well as tree structures etc. > >All data types are stored in the architecture-native format, and a simple >library should be sufficient to parse any dot-proc file. > > >So, we need a small change in procfs that does not in any way break >compatibility - and we need a few lines of C under LGPL to interface with it. > >Tell me what you think - It is possible that I could do this (or something >close) in the near future, unless someone shows me the problem with the >approach. > >Thank you, > see http://sourceforge.net/projects/xmlprocfs/ i think this is a good idea that make the kernel output xml format informations. best regards. zmwillow - 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/