PROPOSAL: /proc standards (was dot-proc interface [was: /proc

PROPOSAL: /proc standards (was dot-proc interface [was: /proc

Post by Ricky Bea » Thu, 08 Nov 2001 06:50:12




>What about adding a separate choice in the kernel config to allow for
>/hproc (or something) human readable /proc file system?

Just think about it for a minute.

There are three ways to address "/proc":
 - 100% binary interface
  * human interaction doesn't belong in the kernel - period.
 - optimally formated text
  * not designed for humans, but in human format ("text")
 - human readable
  * thus the entire OS is reduced to "cat" and "echo"

Providing more than one interface/format means code duplication.  It doesn't
matter how much is actually compiled.  Someone has to write it.  Others have
to maintain it.  Suddenly a change in one place becomes a change in dozens
of places.

Personally, I vote for a 100% binary interface. (no surprise there.)  It
makes things in kernel land so much cleaner, faster, and smaller.  Yes,
it increases the demands on userland to some degree.  However, printf/scanf
is one hell of a lot more wasteful than a simple mov.

For my worst case scenerio, answer this:
  How do you tell how many processors are in a Linux box?

The kernel already knows this, but it isn't exposed to userland.  So, one
must resort to ass-backward, stupid shit like counting entries in
/proc/cpuinfo.  And to make things even worse, the format is different for
every arch! (I've been *ing about this for four (4) years.)

And for those misguided people who think processing text is faster than
binary, you're idiots.  The values start out as binary, get converted to
text, copied to the user, and then converted back to binary.  How the hell
is that faster than copying the original binary value? (Answer: it isn't.)

And those who *will* complain that binary structures are hard to work with,
(you're idiots too :-)) a struct is far easier to deal with than text
processing, esp. for anyone who knows what they are doing.  Yes, changes
to the struct do tend to break applications, but the same thing happens
to text based inputs as well.  Perhaps some of you will remember the stink
that arose when the layout of /proc/meminfo changed (and broke, basically,
everything.)

--Ricky

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

PROPOSAL: /proc standards (was dot-proc interface [was: /proc

Post by Erik Hense » Thu, 08 Nov 2001 06:50:14




>> >1)  IT SHOULD NOT BE PRETTY.  No tabs to line up columns.  No "progress
>> >bars."  No labels except as "proc comments" (see later).  No in-line labelling.

>> It should not be pretty TO HUMANS. Slight difference. It should
>> be pretty to shellscripts and other applications though.

>I really fail to see your point, it's trivial to make
>files which are easy to read by humans and also very
>easy to parse by shellscripts.

Right, let me rephrase myself. There's no real need for /proc to be pretty
to humans, though it would be nice. Readability by applications should be
the priority though.

Quote:>PROCESSOR=0
>VENDOR_ID=GenuineIntel
>CPU_FAMILY=6
>MODEL=6
>MODEL_NAME="Celeron (Mendocino)"

Nice, it could work. However, the kernel does impose policy in this case
(variable naming policy, that is). But it's a nice compromise between
readability by humans and readability by programs.

--

I'm on the list, no need to Cc: me, though I appreciate one if your
mailer doesn't support the References header.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

PROPOSAL: /proc standards (was dot-proc interface [was: /proc

Post by Paul P Komkoff J » Fri, 09 Nov 2001 07:30:15


-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Replying to Ricky Beam:

Quote:> And those who *will* complain that binary structures are hard to work with,
> (you're idiots too :-)) a struct is far easier to deal with than text
> processing, esp. for anyone who knows what they are doing.  Yes, changes

Just read the whole thread, and got my head explode. Let me reply to random
picked msg.

First, to these who know about kernel-user interaction in, for example,
windows. Win32 API has functions, which fill structs, defined in SDK headers.

Linux kernel is much more light-w ... or maybe for any other reason it does
not have that functions. pity. they can achieve performance you need. and no
need for parsing, yeah. (we also do have X, which implementation is much
more slow than winNT gui).

but.

How much time you will parse a single integer ? Without any text around
needs to be thrown away, optionally with 0x and considered it __int64 ?

This is much better than current /proc, yeah ? Anyway, Linus will keep proc
ASCII, and we don't have another Linus.

So proposed standard for /proc - is a good idea. Let's get rid of
progressbars, percent-o-meters with pseudographics. Maybe we should switch
from single file, for ex, cpuinfo, to dir with many INDIVIDUAL files
containing single number or feature-set in it. Splitting away parts that
need to be formatted in-kernel and then parsed in-user maybe a good decision
'coz ... maybe they are rarely used ?

Another point. Including formatting code in EVERY kernel part that resides in
/proc maybe (as for me) a bad idea - so one can do simple interface,
formatting functions, and switch modules to use them

Another point is writable /proc files - but no one in this thread said
something clever about it and ... maybe discuss it later ?

- --
Paul P 'Stingray' Komkoff 'Greatest' Jr // (icq)23200764 // (irc)Spacebar

-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAjvptKwACgkQyMW8naS07KSA2QCgm0z0ICxmJxqjImrPMk7Denzx
CjIAnRCQ6WYMXa0lOMFFyYoHJpZ0jRuy
=8+oN
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/