lkml.org 
[lkml]   [2001]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] 2.5 PROPOSAL: Replacement for current /proc of shit.
Date
On Sunday 04 November 2001 03:08, Jakob Østergaard wrote:
> Now, if established files in proc could just be stable, so that they would
> not change unless non-backwards-compatible information absolutely must be
> presented, that would be a major step in the right direction. Further, if
> we could find some acceptable compromise between human- and machine-
> readability, as has happened in the past...

The problem is that it is almost impossible to offer human-readable
interfaces that will be backward-compatible. As soon as you have a
well-formatted output, like /proc/partitions, you can not add a new field
without breaking user-space applications.
What you could do is to establish rules for files like /proc/partitions ("if
there are more than 4 space-separated alphanumeric strings per line in
/proc/partitions then ignore the additional fields"), but you won't find such
a rule that is useful for every file and still offers a nice human-readable
format. And it will be quite hard to be sure that everybody really sticks to
these rules. Alternatively you could use a semi-human-readable format like
XML, which several people have proposed, but it seemed like almost nobody
liked it.

IMHO there shouldn't be any 'presentation logic' in the kernel. If you need
the things in a human-friendly format, write a 3 line shell script:

for I in `ls -d /proc/partitions/*` ; do
echo `cat $I/major` `cat $I/minor` `cat $I/blocks` `cat $I/name`
done

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/

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