lkml.org 
[lkml]   [2001]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: PROPOSAL: dot-proc interface [was: /proc stuff]
Date
On November 4, 2001 04:33 pm, Jakob Østergaard 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,

While the basic idea is attractive for a number of reasons, there are more
than a few questions to answer. Take a look at a typical proc function,
meminfo_read_proc for example. Its active ingredient is basically a sprintf
function:

len += sprintf(page+len,
"MemTotal: %8lu kB\n"
"MemFree: %8lu kB\n"
"MemShared: %8lu kB\n"
...,
K(i.totalram),
K(i.freeram),
K(i.sharedram),
...);

What does the equivalent look like under your scheme? Does it remain
localized in one proc routine, or does it get spread out over a few
locations, possibibly with a part of the specification outside the
kernel? Do the titles end up in your dotfile? How do you specify whatever
formatting is necessary to transform a dotfile into normal /proc output? Is
this transformation handled in user space or the kernel? How much library
support is needed?

--
Daniel
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:12    [W:1.275 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site