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

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

[William Knop]

>>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.

If this is the case, why are we using ASCII for everything? If the only 
interface to /proc will be applications, then we could just as well let the 
application turn four bytes into an ASCII IPv4 adddress. We could easily 
have it set up to parse using the format [single byte type identifier (ie 4 
for string with the first byte of "data" being the string length, 1 for 
unsigned int, 2 for signed int, 19 for IPv4, 116 for progress bar, 
etc.)][data]. Let people standardize away. Am I missing the point?

I think every aspect of an OS should be intuitive (so long as it is 
efficient), which IMO /proc isn't. If this means splitting it in two, as 
some have suggested, so be it. It certainly should have a design 
guideline/spec so we may at least be consistant. Just my 2 coppers.


Will Knop
w_knop@hotmail.com

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

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

[Erik Hensema]

William Knop (w_knop@hotmail.com) wrote:
>>>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.
>
>If this is the case, why are we using ASCII for everything? If the only 
>interface to /proc will be applications, then we could just as well let the 
>application turn four bytes into an ASCII IPv4 adddress. We could easily 
>have it set up to parse using the format [single byte type identifier (ie 4 
>for string with the first byte of "data" being the string length, 1 for 
>unsigned int, 2 for signed int, 19 for IPv4, 116 for progress bar, 
>etc.)][data]. Let people standardize away. Am I missing the point?

ASCII is readable by all languages with little programmer effort. In C, you
can use a simple scanf, Perl and shells like plain ascii best.

When /proc is turned into some binary interface we'd need to create little
programs which read the binary values from the files and output them on
their stdout, which is quite cumbersome, IMHO.

>I think every aspect of an OS should be intuitive (so long as it is 
>efficient), which IMO /proc isn't. If this means splitting it in two, as 
>some have suggested, so be it. It certainly should have a design 
>guideline/spec so we may at least be consistant. Just my 2 coppers.

Yes, maintain compatibility for 2.6 and try to dump it for 2.8.

Heck, 95% compatibility could even be achieved using a 100% userspace app
which serves the data over named pipes.

-- 
Erik Hensema (erik@hensema.net)
I'm on the list; no need to Cc: me, though I appreciate one if your mailer
doesn't support the References header.

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

[Ricky Beam]

On 6 Nov 2001, Erik Hensema wrote:
>ASCII is readable by all languages with little programmer effort. In C, you
>can use a simple scanf, Perl and shells like plain ascii best.

Right.  Use scanf and you'll be spending the rest of your life chasing
buffer overflows.  Dealing with text efficiently is not "simple."  If it
were, CS students wouldn't take so long to learn how to process text inputs.

And perl handles binary as well as text.  It can deal with binary faster
than it can text, but most people are too lazy to use binary formats with
perl. (I've seen a few, but they were all custom web applications.)

>When /proc is turned into some binary interface we'd need to create little
>programs which read the binary values from the files and output them on
>their stdout, which is quite cumbersome, IMHO.

So, do you run 'free' or 'cat /proc/meminfo'?  'uptime' or 'cat /proc/uptime'?
'netstat', 'route', 'arp', etc. or root through /proc/net/*?  I bet you use
'ps' instead of monkeying around in all the [0-9]* entries in /proc.  The
fact is, we already have "little programs" converting, shuffling, reformating,
and printing out those values.

However, yes, there are useful "human" elements in /proc.  And they really
are there for the sole benefit of a human (eg. /proc/scsi/scsi, /proc/modules,
/proc/slabinfo, etc.)  The bigger picture is that they don't particularly
belong in "/proc" -- the thing originally created to access the process table
without rooting through /dev/kmem. (Raise your hand if you were around for
this.)

>Yes, maintain compatibility for 2.6 and try to dump it for 2.8.

Heh.  It took how many years to get "2.4" stamped on a version?  I'm guessing
2.5 will not exist for several months and the actual "stable" 2.6 will not
be available until 2005.

>Heck, 95% compatibility could even be achieved using a 100% userspace app
>which serves the data over named pipes.

Screw backwards compatibilty.  Sometimes you have to cut your loses and
move on.  We don't want to end up like Microsoft and the whole brain-fuck
that is their dll world. (Yes, they knew it was stupid.  And yes, they
would love to abandon it, but it's far, far too late.)  We switched to ELF,
abandoned libc4, etc.  Add another to the pile.

--Ricky

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

[Erik Hensema]

On Tue, Nov 06, 2001 at 05:09:28PM -0500, Ricky Beam wrote:
> On 6 Nov 2001, Erik Hensema wrote:
> >When /proc is turned into some binary interface we'd need to create little
> >programs which read the binary values from the files and output them on
> >their stdout, which is quite cumbersome, IMHO.
> 
> So, do you run 'free' or 'cat /proc/meminfo'?  'uptime' or 'cat /proc/uptime'?
> 'netstat', 'route', 'arp', etc. or root through /proc/net/*?  I bet you use
> 'ps' instead of monkeying around in all the [0-9]* entries in /proc.  The
> fact is, we already have "little programs" converting, shuffling, reformating,
> and printing out those values.

Yes, but I meant a program which reads a single binary value and outputs it
as ascii, as a generic layer between the binary /proc and the ascii world
of shell scripts.

I don't like a binary /proc.

> However, yes, there are useful "human" elements in /proc.  And they really
> are there for the sole benefit of a human (eg. /proc/scsi/scsi, /proc/modules,
> /proc/slabinfo, etc.)  The bigger picture is that they don't particularly
> belong in "/proc" -- the thing originally created to access the process table
> without rooting through /dev/kmem. (Raise your hand if you were around for
> this.)

I've been around for six years (that is, six years on Linux, not quite as
long on lkml), which isn't quite long enough, I think.

But I agree: /proc is populated with files that don't really belong there.
Maybe everything should be moved to /kernel? (except for the process info,
offcourse).

[...]

> >Heck, 95% compatibility could even be achieved using a 100% userspace app
> >which serves the data over named pipes.
> 
> Screw backwards compatibilty.  Sometimes you have to cut your loses and
> move on.  We don't want to end up like Microsoft and the whole brain-fuck
> that is their dll world. (Yes, they knew it was stupid.  And yes, they
> would love to abandon it, but it's far, far too late.)  We switched to ELF,
> abandoned libc4, etc.  Add another to the pile.

It will be very, very hard for distributors to create a distribution which
runs one the native 2.6 /proc interface as soon as 2.6 comes out. I think
we must assume rewriting things like procps, init scripts, etc. will only
start as soon as 2.6 comes out. We should provide some transitional period
for userspace to adapt, but make clear to everybody that compatibility
isn't going to last forever.

-- 
Erik Hensema (erik@hensema.net)

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

[lkml user]

> > >Heck, 95% compatibility could even be achieved using a 100% userspace app
> > >which serves the data over named pipes.
> > 
> > Screw backwards compatibilty.  Sometimes you have to cut your loses and
> > move on.  We don't want to end up like Microsoft and the whole brain-fuck
> > that is their dll world. (Yes, they knew it was stupid.  And yes, they
> > would love to abandon it, but it's far, far too late.)  We switched to ELF,
> > abandoned libc4, etc.  Add another to the pile.
> 
> It will be very, very hard for distributors to create a distribution which
> runs one the native 2.6 /proc interface as soon as 2.6 comes out. I think
> we must assume rewriting things like procps, init scripts, etc. will only
> start as soon as 2.6 comes out. We should provide some transitional period
> for userspace to adapt, but make clear to everybody that compatibility
> isn't going to last forever.

You must have forgotten about 2.5 which should serve as a transitional 
period just fine. By the time 2.6.0 is about to be released I'll be damned 
if init scripts and the rest proc related hadn't made their transition.

What was said there about making a transition for the better and M$ dlls 
aswell as ELF binary format and libc4, I'd say ditch it even if we planned
to jump from 2.4 directly to 2.6. 

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

[Albert D. Cahalan]

Erik Hensema writes:
> On Tue, Nov 06, 2001 at 05:09:28PM -0500, Ricky Beam wrote:

>> So, do you run 'free' or 'cat /proc/meminfo'?  'uptime' or 'cat
>> /proc/uptime'?  'netstat', 'route', 'arp', etc. or root through
>> /proc/net/*?  I bet you use 'ps' instead of monkeying around in all
>> the [0-9]* entries in /proc.  The fact is, we already have "little
>> programs" converting, shuffling, reformating, and printing out
>> those values.
> 
> Yes, but I meant a program which reads a single binary value and
> outputs it as ascii, as a generic layer between the binary /proc and
> the ascii world of shell scripts.

The following prints a single value as ASCII for Linux, Solaris,
AIX, Tru64, HP-UX, and any other POSIX system.

ps -o uid= -p 1

This is what you are supposed to do. With the above, you can write
portable shell scripts that work on any UNIX. (real UNIX + Linux)

> Maybe everything should be moved to /kernel? (except for the process info,
> offcourse).
...
> It will be very, very hard for distributors to create a distribution which
> runs one the native 2.6 /proc interface as soon as 2.6 comes out. I think
> we must assume rewriting things like procps, init scripts, etc. will only
> start as soon as 2.6 comes out. We should provide some transitional period
> for userspace to adapt, but make clear to everybody that compatibility
> isn't going to last forever.

The app fixing starts immediately for stuff in /bin. It is all
the k-apps and g-apps that will lag.

Splitting /proc can be done. Start by mounting procfs twice.
Make non-process stuff in /proc invisible, but still available.
Then in /kernel the process stuff can be disabled. The proc fs
code can even register two filesystem types, with different
default mount options. After a while, /proc/cpuinfo and such
can emit warnings. (2.5.z for z>42, and 2.y.z for y>6) Then for
the 3.1 kernel (10 years away?) the old crud gets removed.

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

[john slee]

On Wed, Nov 07, 2001 at 07:22:16PM -0500, Albert D. Cahalan wrote:
> Splitting /proc can be done. Start by mounting procfs twice.
> Make non-process stuff in /proc invisible, but still available.
> Then in /kernel the process stuff can be disabled. The proc fs
> code can even register two filesystem types, with different
                         ^^^^^^^^^^^^^^^^^^^^
			 ||||||||||||||||||||

this is the key part.  two filesystems and union mount should satisfy
backward compatibility needs while lspci and friends are migrating to
/kern.

this makes it a distribution issue, not a kernel issue, and there is no
need for special backwards-compatibility stuff in either kernfs or
procfs.

j.

-- 
R N G G   "Well, there it goes again... And we just sit 
 I G G G   here without opposable thumbs." -- gary larson

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

[Albert D. Cahalan]

john slee writes:
> On Wed, Nov 07, 2001 at 07:22:16PM -0500, Albert D. Cahalan wrote:

>> Splitting /proc can be done. Start by mounting procfs twice.
>> Make non-process stuff in /proc invisible, but still available.
>> Then in /kernel the process stuff can be disabled. The proc fs
>> code can even register two filesystem types, with different
>                         ^^^^^^^^^^^^^^^^^^^^
>                         ||||||||||||||||||||
>
> this is the key part.  two filesystems and union mount should
> satisfy backward compatibility needs while lspci and friends
> are migrating to /kern.
>
> this makes it a distribution issue, not a kernel issue, and
> there is no need for special backwards-compatibility stuff in
> either kernfs or procfs.

No, not a union mount. We didn't have that last time I looked,
and I have some doubts that it would work all that well. Even
if it does work, it doesn't provide drop-in kernel compatibility
and doesn't help encourage transition.

It is possible for a single filesystem driver to register more
than one name. For example, once ext3 is fully trusted it could
register an "ext2" type so that we don't need an ext2 driver or
admin headaches. The sysv filesystem driver does in fact register
itself under several different names for compatibility reasons.

So the code in fs/proc could register both "proc" and "kern".
This lets us keep the code intact while preparing for a future
split into separate drivers.

It would be reasonable to have a proc filesystem that could
hide or disable half of the content -- either process files
or the misc junk.

Let's have a filesystem mounted as type "proc" hide everything
but the process directories by default. You can still read
/proc/cpuinfo, but you can't see it when you do "ls /proc".
Let's have  a filesystem mounted as type "kern" disable the
process directories by default.

During transition, you could specify options to get:

1. today's /proc, with perfect compatibility
2. the above, except "ls /proc" won't show misc junk
3. the above, plus a warning when non-process stuff is touched
4. only the process directories
5. misc junk alone, w/o the process directories

The only difference between "proc" and "kern" is the default.
These would be the same:

mount -t proc -o misc-only /mnt/foo
mount -t kern /mnt/foo

After a while the "proc" default changes to #3, then to #4.
Then a while later support for #1, #2, and #3 dies as today's
proc filesystem is finally split in half. Transition done!

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

[john slee]

On Thu, Nov 08, 2001 at 03:14:32AM -0500, Albert D. Cahalan wrote:
> No, not a union mount. We didn't have that last time I looked,

i was under the impression al viro had them planned for 2.5...
hopefully i'm right as i find them rather useful at times under other
systems (openbsd)

> and I have some doubts that it would work all that well. Even

why not?  the two namespaces should not clash... and i really hope that
there aren't any tools out there referencing proc via inode num.  what
problems do you see?

> if it does work, it doesn't provide drop-in kernel compatibility
> and doesn't help encourage transition.

it doesn't exactly discourage transition either, and i don't see how
changing proc to hide/not hide stuff encourages it.  at some point it
has to be a distribution issue, regardless of the transitioning scheme.

if a union could be made to work (and as above i'd like to know why it
couldn't, if only for my own education :-) it means you don't have to go
removing stuff later on.

> It would be reasonable to have a proc filesystem that could
> hide or disable half of the content -- either process files
> or the misc junk.
> 
> Let's have a filesystem mounted as type "proc" hide everything
> but the process directories by default. You can still read
> /proc/cpuinfo, but you can't see it when you do "ls /proc".
> Let's have  a filesystem mounted as type "kern" disable the
> process directories by default.

imho this violates the principle of least-surprise, although i suppose
if you're mounting the fs you're probably expecting it so its probably
ok.

curious,

j.

-- 
R N G G   "Well, there it goes again... And we just sit 
 I G G G   here without opposable thumbs." -- gary larson

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

[William Knop]

>Yes, but I meant a program which reads a single binary value and >outputs 
>it as ascii, as a generic layer between the binary /proc and >the ascii 
>world of shell scripts.
>
>I don't like a binary /proc.

The binary issue could very easily be solved, as you said, by a small 
generic program to do the conversion. Upside it only shell scripts need 
this, while more advanced (lower level) programs will get better preformance 
out of binary format. Downside? I am not sure I see the problem. If a 
program needs to get a lot of /proc info frequently, a binary interface will 
be faster. Idealistically, do we want the kernel interfaces binary or ascii? 
Do we want them to preform best with (be native to) shell scripts or 
programs?

In any event, is the format of process info (actually should be in /proc) or 
the-other-stuff the issue? If it is the latter, the compatibility issue has 
a fairly easy solution...

>But I agree: /proc is populated with files that don't really belong >there. 
>Maybe everything should be moved to /kernel? (except for the
>process info, offcourse).

I like this idea a lot, and so far I haven't heard any objections, save 
compatability...

>It will be very, very hard for distributors to create a distribution >which 
>runs one the native 2.6 /proc interface as soon as 2.6 comes >out. I think 
>we must assume rewriting things like procps, init >scripts, etc. will only 
>start as soon as 2.6 comes out. We should >provide some transitional period 
>for userspace to adapt, but make >clear to everybody that compatibility 
>isn't going to last forever.

Simple solution is to move /kernel stuff of /proc to /kernel (new format, 
bin, ascii, whatever) and put transition code (old code still serving the 
old format /kernel stuff) serving in /proc. Make the backwards compatibility 
/proc a compile option. That way, userland developers will have time to 
migrate to /kernel (or whatever it should be called). Not too much effort, 
makes userland developers not sweat to death...

Will Knop
w_knop@hotmail.com

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

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

[Miquel van Smoorenburg]

In article <F57jukJ1zkc6g9wHRQa0000b09f@hotmail.com>,
William Knop <w_knop@hotmail.com> wrote:
>
>>Yes, but I meant a program which reads a single binary value and >outputs 
>>it as ascii, as a generic layer between the binary /proc and >the ascii 
>>world of shell scripts.
>>
>>I don't like a binary /proc.
>
>The binary issue could very easily be solved, as you said, by a small 
>generic program to do the conversion. Upside it only shell scripts need 
>this, while more advanced (lower level) programs will get better preformance 
>out of binary format. Downside? I am not sure I see the problem. If a 
>program needs to get a lot of /proc info frequently, a binary interface will 
>be faster. Idealistically, do we want the kernel interfaces binary or ascii? 
>Do we want them to preform best with (be native to) shell scripts or 
>programs?

Both. /proc in ascii for shell scripts etc, and sysctl() in binary
for C programs and the like.

Something like

sysctl(SYSCTL_GET, "fs.file-max", SYSCTL_TYPE_INT, &val, sizeof(val))

It gets you free type checking as well.

Perhaps you even want a opendir()/getdents() type sysctl function
so you can walk the tree without /proc being mounted at all.

Mike.
-- 
"Only two things are infinite, the universe and human stupidity,
 and I'm not sure about the former" -- Albert Einstein.

Re: PROPOSAL: dot-proc interface [was: /proc stuff]

[Petr Baudis]

Hi,

> 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

  I've read the whole thread, but i still don't get it. Your solution doesn't
improve (1) for parsers in scripting languages, where it is frequently far
easier to parse ASCII stuff than messing with binary things, when not almost
impossible. So we don't make any progress here.  And for languages like C,
where this will have most use, there actually is solution and it is working.
So, please, can you enlighten me, what's so wrong on sysctl? It actually
provides exactly what do you want, and you even don't need to bother yourself
with open() etc ;). So it would be maybe better improving sysctl interface,
especially mirroring of all /proc stuff there, instead of arguing about scanf()
:-).

  So can you please explain me merits of your approach against sysctl?

-- 

				Petr "Pasky" Baudis

UN*X programmer, UN*X administrator, hobbies = IPv6, IRC
Real Users hate Real Programmers.
Public PGP key, geekcode and stuff: http://pasky.ji.cz/~pasky/

PROPOSAL: /proc standards (was dot-proc interface [was: /proc stuff])

[Stephen Satchell]

At 08:25 AM 11/6/01 +0100, Jakob Østergaard wrote:
>It seems to me that the sysctl interface does not have any type checking,
>so if for example I want to read the jiffies counter and supply a 32-bit
>field, sysctl will happily give me the first/last 32 bits of a field that
>could as well be 64 bits (bit widths do sometimes change, even on 
>architectures
>that do not change).   How am I to know ?

This fault isn't isolated to the sysctl interface.  Look sometime at the 
ioctl and fcntl interfaces and you will see that they have the same 
problem.  The issue is that the original Unix implementation of the 
special-function interface assumed that only "ints" would be passed around, 
and the need for special interfaces outgrew that assumption.

These functions have been so abused that POSIX refuses to "standardize" 
them; instead, special APIs such as TERMIOS have been devised to put a 
fairly-well defined shell around the most needed of these interfaces.  (How 
the implementer decides to bridge the userland/kernel barrier is not part 
of the specification -- and doesn't need to be.)

The /proc API was developed to solve a specific problem.  Now, people have 
proposed and The Powers That Be have accepted extensions to the /proc 
interface as a superior way to tune the kernel, particularly from shell 
scripts, and to monitor the kernel, again from shell scripts.  It's a good 
thing, actually, in that it preserves the best of the Unix 
mentality:  don't re-invent, reuse.

What this whole discussion boils down to is people who want to tackle the 
symptoms instead of the disease.  The PROBLEM is that we have inadequate 
standards and documentation of the /proc interface in its original ASCII 
form.  The proposed solution does NOTHING to address the real problem -- 
and I understand that because too many people here are so used to using a 
hammer (code) that all problems start looking like nails.

The RIGHT tool to fix the problem is the pen, not the coding pad.  I hereby 
pick up that pen and put forth version 0.0.0.0.0.0.0.0.1 of the Rules of /Proc:

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.

2)  All signed decimal values shall be preceded by the "+" or "-" character 
-- no exceptions.  Implementers:  this is available with *printf formats 
with the + modifier, so the cost of this rule is one character per signed 
value.

3)  All integral decimal values shall be assumed by both programs and 
humans to consist of any number of bits.  [C'mon, people, dealing with 
64-bit or 128-bit numbers is NOT HARD.  If you don't know how, 
LEARN.  bc(1) can provide hints on how to do this -- use the Source, 
Luke.]  Numbers shall contain decimal digits [0-9] only.  Zero-padding is 
allowed.

4)  All floating-point values shall contain a leading sign ("+" or "-") and 
a decimal point (US) or comma (Europe).  This rule assumes that the locale 
for the kernel can be set; if this isn't true, then a period shall be used 
to separate the integral part and the fractional part.  Floating point 
values may also contain exponents (using the *printf format %E or %G, NOT 
%e -- the exponent must be preceded by the letter "e" or "E").  The 
specification of a zero precision (which suppresses the output of the 
decimal point or comma) is prohibited.

5)  All string values matching the regular expression [!"$-+--~]* shall be 
output as they are.  Strings that do not match the above regular expression 
shall be escaped in a standard manner, using a single routine provided in 
the kernel's /proc interface to provide the proper escape sequences.  The 
output of that routine shall output standard backslash-character 
representation of standard C-language control characters, and 3-digit octal 
representation of any other character encountered.  Output of the octal 
representation may be truncated when such truncation would not cause 
confusion -- see strace(1) for examples.

6)  If you are wanting to display octal data, display it byte at a time 
with a backslash.  If you want to display hexadecimal data, use the "\x" 
introduction, but include all bits so that the using program knows how long 
the damn element is supposed to be -- NO leading -zero suppression should 
be done.  (Use the %x.xX format item in *printf, where "x" is the number of 
hexadecimal digits.)

7)  The /proc data may include comments.  Comments start when an  unescaped 
hash character "#" is seen, and end at the next newline \n.  Comments may 
appear on a line of data, and the unescaped # shall be treated as end of 
data for that line.

8)  The regular expression ^#!([A-Za-z0-9_.-]+ )*[A-Za-z0-9_.-]$ defines a 
special form of comment, which may be used to introduce header labels to an 
application.  As shown in the regular expression, each label is defined by 
the regular subexpression [A-Za-z0-9_.-]+ and are separated by a single 
space.  The final (or only) label is terminated by a newline \n.  No data 
may appear on the header comment line.  This line may only appear at the 
beginning of the /proc pseudo file, and appears only ONCE.

9) The regular expression ^#=[0-9]+$ shall be used to output a optional 
"version number" comment line  If this appears in the /proc output, it 
precedes the header comment line, and appears only ONCE.

10)  Network addresses are defined as strings, either in their name form, 
in dot quad notation for IPV4 numeric addresses, or in the numeric 
equivalent for IPV6.  Parsers can recognize the difference between a 
dot-quad IP address and a floating-point number by the presence of the 
second dot in the number.  Network information output on /proc shall not 
use the base/mask notation (123.456.789.012/255.255.255.0) and instead use 
the bit-length notation (123.456.789.012/24).

11)  IPX network addresses are a problem.  In their normal form, they are 
indistinguishable from a %F-format floating-point number with leading zeros 
(which is allowed).  Therefore the dot that usually appears in an IPX 
network number must be replaced with the hyphen or dash "-" 
character.  Parsers can then differentiate an IPX network address from a 
floating point number by noticing the embedded dash without the leading "e" 
or "E" character.  Flex handles this just fine.

-end-

This represents my first cut into a specification for the /proc interface 
to deal with some of the issues that have come up in this thread.  It's not 
going to satisfy the "performance for me at all costs, DAMMIT" people and 
it's not going to satisfy the "I like it PRETTY, DAMMIT" crowd either, but 
it would provide a means for coming up with some standard tools to deal 
with /proc, and a way to reign in the madness.

In particular, it means that a single tool could be developed to take a 
/proc file and, in userland, make it a little more pretty.  Those that 
don't like table presentations can use the source of the tool to make a 
display more to their liking.

The spec has a number of things missing.  One issue missing is how to make 
a predictable /proc subtree, so that people can find the goodies more 
easily.  Another issue is specifying how /proc can be used to set 
parameters.  (We seem to have less confusion in this area, so I didn't want 
to spend any time on this aspect of the specification.)

OK, I'm clear of the firing range, start shooting holes in it.

Stephen Satchell

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

[Erik Hensema]

Stephen Satchell (satch@concentric.net) wrote:
>The RIGHT tool to fix the problem is the pen, not the coding pad.  I
>hereby pick up that pen and put forth version 0.0.0.0.0.0.0.0.1 of the
>Rules of /Proc:

Agreed.

>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.

Yes, that means we won't be able to do a 'cat /proc/cpuinfo' anymore in the
future. Bummer.

>2)  All signed decimal values shall be preceded by the "+" or "-" character 
>-- no exceptions.  Implementers:  this is available with *printf formats 
>with the + modifier, so the cost of this rule is one character per signed 
>value.

Why?

>3)  All integral decimal values shall be assumed by both programs and 
>humans to consist of any number of bits.  [C'mon, people, dealing with 
>64-bit or 128-bit numbers is NOT HARD.  If you don't know how, 
>LEARN.  bc(1) can provide hints on how to do this -- use the Source, 
>Luke.]  Numbers shall contain decimal digits [0-9] only.  Zero-padding is 
>allowed.

Ack.

>4)  All floating-point values shall contain a leading sign ("+" or "-") and 
>a decimal point (US) or comma (Europe).  This rule assumes that the locale 
>for the kernel can be set; if this isn't true, then a period shall be used 
>to separate the integral part and the fractional part.  Floating point 
>values may also contain exponents (using the *printf format %E or %G, NOT 
>%e -- the exponent must be preceded by the letter "e" or "E").  The 
>specification of a zero precision (which suppresses the output of the 
>decimal point or comma) is prohibited.

As long as I can parse it easily, it's fine by me. Easily parsable -> not
localised! Localisation is for userspace, not for the kernel.

[...]

>7)  The /proc data may include comments.  Comments start when an  unescaped 
>hash character "#" is seen, and end at the next newline \n.  Comments may 
>appear on a line of data, and the unescaped # shall be treated as end of 
>data for that line.

Please don't do this. I want to be able to do 'read JIFFIES <
/proc/$jiffiesfile'. Make the name of the file speak for itself. One field
per file in a clearly defined format.

>8)  The regular expression ^#!([A-Za-z0-9_.-]+ )*[A-Za-z0-9_.-]$ defines a 
>special form of comment, which may be used to introduce header labels to an 
>application.  As shown in the regular expression, each label is defined by 
>the regular subexpression [A-Za-z0-9_.-]+ and are separated by a single 
>space.  The final (or only) label is terminated by a newline \n.  No data 
>may appear on the header comment line.  This line may only appear at the 
>beginning of the /proc pseudo file, and appears only ONCE.
>
>9) The regular expression ^#=[0-9]+$ shall be used to output a optional 
>"version number" comment line  If this appears in the /proc output, it 
>precedes the header comment line, and appears only ONCE.

You don't need 8) and 9) when using single fields in a file. Multiple
fields are pretty to a human but not to a simple script.

Optionally doing a 
while read MOUNTPOINT DIR OPTS ; do
	# blah
done < /proc/$mountfile

Would be acceptable.

>10)  Network addresses are defined as strings, either in their name form, 
>in dot quad notation for IPV4 numeric addresses, or in the numeric 
>equivalent for IPV6.  Parsers can recognize the difference between a 
>dot-quad IP address and a floating-point number by the presence of the 
>second dot in the number.  Network information output on /proc shall not 
>use the base/mask notation (123.456.789.012/255.255.255.0) and instead use 
>the bit-length notation (123.456.789.012/24).

You should already know you're going to read an IP address to begin with.

>11)  IPX network addresses are a problem.  In their normal form, they are 
>indistinguishable from a %F-format floating-point number with leading zeros 
>(which is allowed).  Therefore the dot that usually appears in an IPX 
>network number must be replaced with the hyphen or dash "-" 
>character.  Parsers can then differentiate an IPX network address from a 
>floating point number by noticing the embedded dash without the leading "e" 
>or "E" character.  Flex handles this just fine.

See 10).


As you can see, I don't really care about the user reading /proc. We should
provide a backwards compatible /proc to avoid major backage, so users would
be able to read from this interface. Please keep the new interface to the
applications, as it should have been from the start.

And yes, coding a cpuinfo.sh would be very, very easy, so we (the users)
don't need the old interface anyway.

-- 
Erik Hensema (erik@hensema.net)                             ICQ# 8280101
Registered Linux user #38371 -- http://counter.li.org
--S279844AbRKFT36=_/vger.kernel.org--

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

[Roy Sigurd Karlsbakk]

> >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.
>
> Yes, that means we won't be able to do a 'cat /proc/cpuinfo' anymore in the
> future. Bummer.

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

--
Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA

Computers are like air conditioners.
They stop working when you open Windows.

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

[Ricky Beam]

On Tue, 6 Nov 2001, Roy Sigurd Karlsbakk wrote:
>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 bitching 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

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

[Alexander Viro]

On Tue, 6 Nov 2001, Ricky Beam wrote:

[snip]
> 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

Learn C, then learn some respect to your betters[1], then come back.

*PLONK*

[1] like, say it, guys who had invented UNIX and C.

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

[Alex Bligh - linux-kernel]

--On Tuesday, 06 November, 2001 5:14 PM -0500 Alexander Viro 
<viro@math.psu.edu> wrote:

> On Tue, 6 Nov 2001, Ricky Beam wrote:
>
> [snip]
>> 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
>
> Learn C, then learn some respect to your betters[1], then come back.
>
> *PLONK*
>
> [1] like, say it, guys who had invented UNIX and C.

What amuses me about those arguing for binary structures as a long term
solution for communicating, on a flexible but long lived basis, is that the
entire OS Genre they appear to be advocating (UNIX et al.) has been doing
this, on an app to app (as opposed to kernel to app) basis, for far longer
than most of them can remember, in situations where performance is far more
relevant, and pitted against far more 3l33t 5tud3nt2 than we we shake a
stick at, but /still/ they persist.

Through minor local idiocy, I had trashed my local lilo partition, and had
to try and boot with a Debian CD-Rom with a 2.2 kernel. I forgot to ask for
single user more. Not only did it boot first time, it booted fully, apart
from two minor things: no iptables, and (shock horror) the sound card
didn't work it wasn't compatible. Similarly, I've loaded 2.4 kernels with
no problems onto 2.2 systems.

This "dreadful" /proc interface everyone talks about has been *STAGGERINGLY
GOOD* in terms of forward and backward compatibility. Sure, the innards may
smell unpleasant, but I reckon the interface, in practice, whilst not in
BNF format (BTW what is, and and, for the compsci philosophers amongst you,
'.*' as a regexp is easilly convertible into BNF and describes the /proc
interface completely - lexical and synatical analysis is immaterial without
tight semantic definition), has worked well just because kernel developers
and maintainers have showed themselves unwilling to break existing
userspace tools, and vice versa.

I think/thought we learnt our lesson on this in the fallout of the
Net2E/Net2D 'debate'. If someone is willing to stand up and say that /proc
external interface causes as many problems as the networking code did at
the time, please stand up and be counted now, preferably holding your
thesis on how to fix this for inter-app comms in Un*x in general, & forming
an orderly queue for the exit door :-)

--
Alex Bligh

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

[Albert D. Cahalan]

Alex Bligh - linux writes:

> What amuses me about those arguing for binary structures as a long term
> solution for communicating, on a flexible but long lived basis, is that the
> entire OS Genre they appear to be advocating (UNIX et al.) has been doing
> this, on an app to app (as opposed to kernel to app) basis, for far longer
> than most of them can remember, in situations where performance is far more
> relevant, and pitted against far more 3l33t 5tud3nt2 than we we shake a
> stick at, but /still/ they persist.

quotas, process accounting, wtmp, utmp, Tux web server logs...

> Through minor local idiocy, I had trashed my local lilo partition,
> and had to try and boot with a Debian CD-Rom with a 2.2 kernel. I
> forgot to ask for single user more. Not only did it boot first time,
> it booted fully, apart from two minor things: no iptables, and
> (shock horror) the sound card didn't work it wasn't compatible.
> Similarly, I've loaded 2.4 kernels with no problems onto 2.2 systems.
>
> This "dreadful" /proc interface everyone talks about has been
> *STAGGERINGLY GOOD* in terms of forward and backward compatibility.
...
> has worked well just because kernel developers and maintainers
> have showed themselves unwilling to break existing userspace
> tools, and vice versa.

I can see that you are unfamiliar with the /proc filesystem.

You can change kernels because app developers work hard to
be tolerant of stupid /proc changes. Some of the crap that
I've stumbled across, mostly while doing procps work:

/proc/*/stat signal info was changed from decimal to hex for
a while. I changed it back, but too late: the evil hex had
already leaked out into the world, and I had to modify libproc.
Quick, is 16785472 in decimal or hex? So use the "friendly" new
/proc/*/status file instead, but...

The "SigCgt" in /proc/*/status wasn't always spelled that way.
It wasn't always in the same location either, so what to do?
That calls for another hack: assume signal values follow each other.

Kernel threads don't have memory info. Somebody added "kB" on the
end of most lines in /proc/meminfo. /proc/stat has changed in ways
that I'm glad to have forgotten. /proc/interrupts has been through
a flood of horrid changes: the PIC type going from "" to "XT PIC"
to "XT-PIC", the last column getting spaces (consider "XT PIC"!),
a new header (just waiting for extra info) and a variable number
of per-CPU columns in the middle to replace what was once a total.
Maybe /proc/cpuinfo is the worst... I hear SPARC is pretty smelly,
but hey, every arch screws app developers in some unique way.

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

[Alexander Viro]

On Wed, 7 Nov 2001, Albert D. Cahalan wrote:

> /proc/*/stat signal info was changed from decimal to hex for
> a while.

And _THAT_ should be a reason for immediate and severe LARTing.
That (and wankfests with progress bars, yodda, yodda) needs to
be stopped.  But notice that switching to binary or doing
tags, etc. has nothing to that - same breakage will continue
with them unless you LART lusers who do it.  Which works (or
doesn't) regardless of API.

Random API changes (and as a flipside of the same, APIs that
had never been thought through) are crap and they should be
dealt with.  However, if you think that switching to binary
is going to make people think what they are doing... there's
a nice bridge I'd like to sell.

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

[Alex Bligh - linux-kernel]

--On Wednesday, November 07, 2001 2:20 AM -0500 "Albert D. Cahalan" <acahalan@cs.uml.edu> wrote:

> I can see that you are unfamiliar with the /proc filesystem.
>
> You can change kernels because app developers work hard to
> be tolerant of stupid /proc changes.
> Some of the crap that
> I've stumbled across, mostly while doing procps work:

My point is two-fold:

1. Sure, you (and no doubt others) had to do lots
   of work fixing userland, which
   you shouldn't have had to do. But that seems to be
   more down to lack of discipline in interface changes
   rather than because the interface isn't binary. I am
   sure it's easier to strip out a spurious 'kb' that
   gets added after a number, than to deal with (say)
   an extra inserted DWORD with no version traching.

2. The system survived. The interface was there. Bload
   sweat and tears were no doubt expended, possibly by
   the wrong people, but in practice the interface worked,
   (no, not optimally). I'd suggest even with it's badly
   managed changes, thouse have been less disruptive than
   many other non-ascii based conventions (I'm thinking
   back to Net-2E/2D). Sure, wtmp, utmp have been stable.
   Not sufficiently familiar with process accounting or
   quotas, though I have some possibly incorrect memory
   of the latter suffering some format change which was
   generated compatibility problems with user space tools?

--
Alex Bligh

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

[Blue Lang]

As an admin, I have to say that there are few things in the world that
cheese me off more than binary logging/statistics. If you change all of
/proc to binary and assume that userspace tools will keep up with changes,
you're eliminating the use of my personal most common set of proc parsing
tools: cat and grep.

With binary, the assumption is made that someone is actually going to
maintain all of those tools, as well as that admins will actually be able
to keep them all straight. It just reeks of AIXness, with the lspv and the
giant nasty ODM database.

I understand where the binary crowd is coming from as far as collation
goes, but I personally use the simple stuff every day (cat /proc/pci) and
any sort of aggregate/collation tool (lspci) almost never.

-- 
   Blue Lang, editor, b-side.org                     http://www.b-side.org
   2315 McMullan Circle, Raleigh, North Carolina, 27608       919 835 1540

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

[Ricky Beam]

On Wed, 7 Nov 2001, Blue Lang wrote:
>I understand where the binary crowd is coming from as far as collation
>goes, but I personally use the simple stuff every day (cat /proc/pci) and
>any sort of aggregate/collation tool (lspci) almost never.

Just as an aside, /proc/pci was slated for deletion a long time ago.  There
were warnings emitted by the kernel every time something accessed it for
some time.  /proc/pci is dependent on a (large) list of names being in the
kernel to map the numbers to text.  I think the plans to kill /proc/pci
have been abandoned, however. (The table makes the kernel big, but most of
it gets released once the pci bus scan is complete ala __init_data.)

As for code maint. and kernel changes breaking things... both happen already
with the text based system.  Binary structures can be constructed to be
extensible without breaking old tools.  Plus, the information exported from
the kernel (in the case of processes) need not change with every version
of the kernel.

I don't think people realize just how many CPU cycles are being needlessly
expended in passing information between the kernel and the user.  When I
have the time, I'll add binary interfaces for various things and show exactly
how expensive the existing system is -- all for the sake of being able to
use 'cat' and 'grep'.

--Ricky

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

[Kai Henningsen]

jfbeam@bluetopia.net (Ricky Beam)  wrote on 07.11.01 in <Pine.GSO.4.33.0111071409530.17287-100000@sweetums.bluetronic.net>:

> As for code maint. and kernel changes breaking things... both happen already
> with the text based system.  Binary structures can be constructed to be
> extensible without breaking old tools.  Plus, the information exported from
> the kernel (in the case of processes) need not change with every version
> of the kernel.

And the exact same thing can be done with ASCII, too - only easier.

> I don't think people realize just how many CPU cycles are being needlessly
> expended in passing information between the kernel and the user.  When I
> have the time, I'll add binary interfaces for various things and show
> exactly how expensive the existing system is -- all for the sake of being
> able to use 'cat' and 'grep'.

I consider those cycles *very* well spent. Being able to use those common  
tools is rather important to very many people.

Let's write a /proc ASCII coding rules document. It should document well a  
few (*very* few) generic formats to use for new entries, and big fat  
warnings about ever changing the format of existing tables, and it should  
be easy to find in /Documentation/ - and we should immediately jump on  
anyone who violates it without, in advance, discussing the problem he's  
trying to solve, and convincing us that they can't be solved any other  
way.

I don't much care how those formats look, as long as they're easy to parse  
and to extend compatibly, and *few*.

MfG Kai

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

[Albert D. Cahalan]

Alex Bligh - linux writes:

>    sure it's easier to strip out a spurious 'kb' that
>    gets added after a number, than to deal with (say)
>    an extra inserted DWORD with no version traching.

Design the kernel to make doing this difficult.
Define some offsets as follows:

#define FOO_PID 0
#define FOO_PPID 1

Now, how is anyone going to create "an extra inserted DWORD"
between those? They'd need to renumber FOO_PPID and any other
values that come after it.

The "DWORD" idea is messed up too BTW. Use __u64 everywhere.

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

[Alex Bligh - linux-kernel]

> Design the kernel to make doing this difficult.
> Define some offsets as follows:
>
># define FOO_PID 0
># define FOO_PPID 1
>
> Now, how is anyone going to create "an extra inserted DWORD"
> between those? They'd need to renumber FOO_PPID and any other
> values that come after it.

For instance, take the /proc/mounts type example, where
each row is a sequence of binary values. Someone decides
to add another column, which assuming it is a DWORD^W__u64,
does exactly this, inserts a DWORD^W__u64 between the
end of one record and the start of the next as far a
poorly written parser is concerned.

The brokenness is not due to the distinction between ASCII
and binary. The brokenness is due the ill-defined nature
of the format, and poor change control. (so for instance
the ASCII version could consistently use (say) quoted strings,
with spaces between fields, and \n between records, just
as the binary version could have a record length entry at the
head of each record, and perhaps field length and identifier
versions by each field - two very similar solutions to the
problem above).

> The "DWORD" idea is messed up too BTW. Use __u64 everywhere.

OK OK :-)

--
Alex Bligh

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

[Ricky Beam]

On Thu, 8 Nov 2001, Alex Bligh - linux-kernel wrote:
>For instance, take the /proc/mounts type example, where

(bad example as /proc/mounts is supposed to be a substiture for /etc/mtab.)

>each row is a sequence of binary values. Someone decides
>to add another column, which assuming it is a DWORD^W__u64,
>does exactly this, inserts a DWORD^W__u64 between the
>end of one record and the start of the next as far a
>poorly written parser is concerned.

Then make it hard ("impossible") to write a poor parser; include a record
size in the data format.  The first __u32 read is the number of bytes per
record.  You then know exactly how much data to read.  Adding more crap on
the end doesn't break anything.

People who think binary data formats are bad and hard to work with should
take a few minutes to look at various implementation using binary data
structures.  For example, RADIUS.

>The brokenness is not due to the distinction between ASCII
>and binary. The brokenness is due the ill-defined nature
>of the format, and poor change control. (so for instance
>the ASCII version could consistently use (say) quoted strings,
>with spaces between fields, and \n between records, just
>as the binary version could have a record length entry at the
>head of each record, and perhaps field length and identifier
>versions by each field - two very similar solutions to the
>problem above).

Correct.  The issue is not which is easier to work with, or endian friendly.
A properly designed structure, which we still don't have, is the key.  It's
just as straight forward to tokenize binary fields as text fields.  Then you
have to do something with the data in the fields.  Binary is far more
efficient in almost all cases.

People should not shit a brick at the suggestion of doing _some_ things
as binary structures.  The parts of /proc that really are intended for humans
(ie. driver "debug" information... /proc/slabinfo, /proc/drivers/rd/..., etc.)
don't make sense in binary.  However, there are loads of things that DO make
sense in binary format -- too many things reference them for further processing
requiring conversion from/to text multiple times.  The number of people
who do:
 % grep -l foo /proc/[0-9]*/cmdline
instead of:
 % ps auxwww | grep foo
are very VERY low.

--Ricky

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

[Albert D. Cahalan]

Alex Bligh - linux writes:
> [Albert Cahalan]

>> Design the kernel to make doing this difficult.
>> Define some offsets as follows:
>> 
>> # define FOO_PID 0
>> # define FOO_PPID 1
>> 
>> Now, how is anyone going to create "an extra inserted DWORD"
>> between those? They'd need to renumber FOO_PPID and any other
>> values that come after it.
>
> For instance, take the /proc/mounts type example, where
> each row is a sequence of binary values. Someone decides
> to add another column, which assuming it is a DWORD^W__u64,
> does exactly this, inserts a DWORD^W__u64 between the
> end of one record and the start of the next as far a
> poorly written parser is concerned.

That would be a botched design to begin with.

Each row becomes a separate binary file. They are distinct
records anyway. Splitting by column would be a poor choice.

> The brokenness is not due to the distinction between ASCII
> and binary. The brokenness is due the ill-defined nature
> of the format, and poor change control.

ASCII encourages ill-defined formats and poor change control.
People make assumptions about what is valid.

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

[bill davidsen]

In article <Pine.GSO.4.33.0111081612240.17287-100000@sweetums.bluetronic.net>
	jfbeam@bluetopia.net wrote:

| People should not shit a brick at the suggestion of doing _some_ things
| as binary structures.  The parts of /proc that really are intended for humans
| (ie. driver "debug" information... /proc/slabinfo, /proc/drivers/rd/..., etc.)
| don't make sense in binary.  However, there are loads of things that DO make
| sense in binary format -- too many things reference them for further processing
| requiring conversion from/to text multiple times.  The number of people
| who do:
|  % grep -l foo /proc/[0-9]*/cmdline
| instead of:
|  % ps auxwww | grep foo
| are very VERY low.

  There's a great savings, to convert what is initially a text string to
some "binary" format.

  The advantage of text format is that humans can read it, and if it
changes they can almost always figure out what it means. Not everyone is
a C/PERL hacker who is happy writing machine independent binary
structures, while virtually every language ever written can and will
parse those text strings, and when it won't you can see why not.

  Having spent a lot of time developing tools to use the contents of
/proc, I have to feel that the savings in time of not reinventing every
existing wheel is so far in excess of any possible saving that
justifying the change on effeciency grounds is at best unconvincing.

  There are so many new and useful things which could be done that I
can't imaging this make-work change to something currently in place to
be a useful investment of time.

-- 
bill davidsen <davidsen@tmr.com>
  His first management concern is not solving the problem, but covering
his ass. If he lived in the middle ages he'd wear his codpiece backward.

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

[Martin Dalecki]

Ricky Beam wrote:

> 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 then converted back to ASCII for printout on the terminal ;-).
 
> 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.)

Amen.

The true problem with /proc and user land applications is that around 6
years
ago people did just give up on adapting the parsers to the ever chaning
"wonderfull" ascii interfaces those times. The second problem is that
/proc
is one of the few design "inventions" in linux, which didn't get copied
over
from some other UNIX box and Linus doesn't wan't recognize that this was
A BAD DESIGN CHOICE.

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

[Alex Bligh - linux-kernel]

--On Wednesday, 07 November, 2001 1:13 AM +0100 Martin Dalecki 
<dalecki@evision-ventures.com> wrote:

> around 6 years
> ago people did just give up on adapting the parsers to the ever chaning
> "wonderfull" ascii interfaces those times.

Must have passed me by - probably too busy with regedt32 and other
such great /proc substitutes - cough...

--
Alex Bligh

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

[Ricky Beam]

On Wed, 7 Nov 2001, Martin Dalecki wrote:
>And then converted back to ASCII for printout on the terminal ;-).

Well, they don't always get printf()'d...

>The second problem is that /proc is one of the few design "inventions" in
>linux, which didn't get copied over from some other UNIX box and Linus
>doesn't wan't recognize that this was A BAD DESIGN CHOICE.

/proc is a wonderful thing for what it was originally intended: access to
the process table without looking at the tables in the kernel memory space
(remember SunOS?  what happened if /vmunix wasn't the running kernel?)
Unfortunately, /proc has become the gheto of the Linux kernel.  It is now
the general dumping grounds for user/kernel interfacing.  As a developer tool
it's very handy; it's also very dangerous.  Developers then resort to
/proc as a perminant interface between kernel drivers and userland. (In
the *BSD world, this is a kernfs, not a procfs.)

For an example of /proc done right, find a Solaris box.  What do you find
in /proc?  Gee, process information.  Only process information.  In. Binary.

--Ricky

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

[Alex Bligh - linux-kernel]

--On Tuesday, 06 November, 2001 8:10 PM -0500 Ricky Beam 
<jfbeam@bluetopia.net> wrote:

> /proc ... it's very handy; it's also very dangerous.

as is most of UID==0 UNIX; and the problem here is?

--
Alex Bligh

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

[Martin Dalecki]

Ricky Beam wrote:

> For an example of /proc done right, find a Solaris box.  What do you find
> in /proc?  Gee, process information.  Only process information.  In. Binary.

Amen. I have enough of them at hand. And I don't miss any "wonderfull"
functionality
from linux /proc if I'm working on them.

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

[Remco Post]

> On Tue, 6 Nov 2001, Roy Sigurd Karlsbakk wrote:
> >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 bitching 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
> 

Hi,

the nice thing about text interface as opposed to a struct is that the userland can parse a "CPU_FAMILY=6" as good as 0x6, but if you decide to change the format of the /proc entry, with a binary interface, this means you MUST update the userland as well, while with a text interface and some trivial error processing, adding a field would in the worst case mean that the userland app will not profit from the new info, but it will NOT BREAK.

I do realize this means that the userland apps have to be carefully designed and implemented, but at least, a kernel upgrade wouldn't imply an upgrade of half the OS tools. Once programmers start to realize that error processing is a must anyway, this is a trivial step (and no, "Your proc is broken, go fix it" messages are not error processing ;).

-- 
Met vriendelijke groeten,

Remco Post

SARA - Stichting Academisch Rekencentrum Amsterdam
High Performance Computing  Tel. +31 20 592 8008    Fax. +31 20 668 3167

"I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course - the computer industry
didn't even foresee that the century was going to end." -- Douglas Adams

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

[Albert D. Cahalan]

Remco Post writes:

> the nice thing about text interface as opposed to a struct is that
> the userland can parse a "CPU_FAMILY=6" as good as 0x6, but if you
> decide to change the format of the /proc entry, with a binary
> interface, this means you MUST update the userland as well, while
> with a text interface and some trivial error processing, adding a
> field would in the worst case mean that the userland app will not
> profit from the new info, but it will NOT BREAK.

Add something to /proc/*/status between SigIgn and SigCgt.
Stuff breaks because apps that use SigCgt must simply assume
that it comes after SigIgn due to somebody changing the
way SigCgt gets spelled. (it was SigCat maybe)

I'd expect many apps to have stack overflows if you add stuff.
Sure, you could say that's bad user code, but it happens.

For a binary format, you DO NOT need to update user apps any
more than you would for text. I don't see why people think
this is so hard. Let's design a /proc/*/foo file.

#define FOO_PID 0
#define FOO_PPID 1
#define FOO_PGID 2
#define FOO_SIG_IGN 3
#define FOO_FILENAME 4
#define FOO_STATE 5
#define FOO_VM_LOCKED 6

__u64 foo[7];

Now you want to expand things. Fine. If anything goes from 16 bits
to 32 bits, well, we already have padding for it. Suppose Linus
finally sees the light about signals, adding an extra 64. In that
case, we just add FOO_SIG_IGN_HIGH for the top bits and increase
the array size by one. Old apps don't read that and don't care.
The same goes for FOO_FILENAME, with old apps getting truncation
at 8 bytes and new apps getting truncation at 16 bytes. Now maybe
we decide that FOO_STATE is obsolete -- we all have hyperthreaded
processors that handle thousands of threads and nothing ever blocks.
No problem, just have the kernel supply a dummy value to keep the
old apps happy.

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

[Paul P Komkoff Jr]

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

Replying to Ricky Beam:
> 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
  PPKJ1-RIPE // (smtp)i@stingr.net // (http)stingr.net // (pgp)0xA4B4ECA4
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAjvptKwACgkQyMW8naS07KSA2QCgm0z0ICxmJxqjImrPMk7Denzx
CjIAnRCQ6WYMXa0lOMFFyYoHJpZ0jRuy
=8+oN
-----END PGP SIGNATURE-----

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

[Phil Howard]

Paul P Komkoff Jr wrote:

> 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 ?

And it's not much even with letters following like "k" and "m".


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

Do we need another?


> 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 ?

Sounds like a lot more open() calls to me.  If one is insisting on
saving CPU time (be it in kernel space or user space), I doubt if
this accomplishes that.  Not that that is everyone's goal.


> 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

So a common core formatter for everything?  That could be done in
userspace or as a module, right?  Insert the module (or compile it
in directly) and /kerntxt becomes mountable and mirrors /kernel but
in text format.  How about a FS type for making any arbitrary info
tree much like /proc but served via a user space process?  Then it
can get the info from somewhere else, format it, and hand it back.
It could have other uses besides just /proc stuff.


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

Those tend to be single value writes, true?  If in binary format,
then there will need to be a "setkernel" comand or some such thing
which opens the named path, and writes the data in the indicated
binary format.

So instead of:
    echo 0 > /proc/sys/net/ipv4/tcp_ecn
you might have:
    setkernel /kernel/sys/net/ipv4/tcp_ecn -i4 0


FYI: I really don't care much how this gets formatted or reformatted,
as long as it isn't XML (worst of both worlds: more CPU to parse and
breaks cat and grep).  Logical is nice.  Fast is nice.  Compact is
nice.  Readable is nice.  Easy to code in scripts is nice.  Easy to
code in C is nice.  The ultimate solution to make it possible to have
all these features at the same time ... priceless.

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam@ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------

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

[Rik van Riel]

On 6 Nov 2001, Erik Hensema wrote:

> >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.

PROCESSOR=0
VENDOR_ID=GenuineIntel
CPU_FAMILY=6
MODEL=6
MODEL_NAME="Celeron (Mendocino)"
.....

As you can see, this is easily readable by humans,
while "parsing" by a shell script would be as follows:

. /proc/cpuinfo

After which you could just "echo $PROCESSOR" or
something like that ...

Yes, this is probably a bad example, but it does show
that machine-readable and human-readable aren't mutually
exclusive.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

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

[Erik Hensema]

Rik van Riel (riel@conectiva.com.br) wrote:
>On 6 Nov 2001, Erik Hensema wrote:
>
>> >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.

>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.

-- 
Erik Hensema (erik@hensema.net)
I'm on the list, no need to Cc: me, though I appreciate one if your
mailer doesn't support the References header.

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

[Tim Jansen]

On Tuesday 06 November 2001 22:24, Rik van Riel wrote:
> 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.
> PROCESSOR=0
> VENDOR_ID=GenuineIntel
> CPU_FAMILY=6
> MODEL=6
> MODEL_NAME="Celeron (Mendocino)"

Wow, this is a good one...

bye..

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

[Erik Andersen]

On Tue Nov 06, 2001 at 07:24:13PM -0200, Rik van Riel wrote:
> 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.
> 
> PROCESSOR=0
> VENDOR_ID=GenuineIntel
> CPU_FAMILY=6
> MODEL=6
> MODEL_NAME="Celeron (Mendocino)"
> .....
> 
> As you can see, this is easily readable by humans,
> while "parsing" by a shell script would be as follows:
> 
> . /proc/cpuinfo
> 
> After which you could just "echo $PROCESSOR" or
> something like that ...

I think we have a winner!  If we could establish this 
as policy that would be _sweet_!

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

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

[Jan-Benedict Glaw]

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
> > CPU_FAMILY=6
> > MODEL=6
> > MODEL_NAME="Celeron (Mendocino)"
> > .....

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?

MfG, JBG

-- 
Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481

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

[Erik Andersen]

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
> > > CPU_FAMILY=6
> > > MODEL=6
> > > MODEL_NAME="Celeron (Mendocino)"
> > > .....
> 
> 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
CPU_FAMILY_0=6
MODEL_0=6
MODEL_NAME_0="Celeron (Mendocino)"
...

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

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

[Jan-Benedict Glaw]

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

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

[Patrick Mochel]

On Tue, 6 Nov 2001, Erik Andersen wrote:

> 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
> > > > CPU_FAMILY=6
> > > > MODEL=6
> > > > MODEL_NAME="Celeron (Mendocino)"
> > > > .....
> >
> > 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
> CPU_FAMILY_0=6
> MODEL_0=6
> MODEL_NAME_0="Celeron (Mendocino)"
> ...

(Though I think all caps variables are ugly, I can concede)

How about

$ cat /proc/cpus/0

PROCESSOR=0
VENDOR_ID=GenuineIntel
CPU_FAMILY=6
MODEL=6
MODEL_NAME="Celeron (Mendocino)"
.....

$ for i in `ls /proc/cpus/` ; do
	cat $i
  done
...


	-pat

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

[Erik Andersen]

On Tue Nov 06, 2001 at 02:53:27PM -0800, Patrick Mochel wrote:
> How about
> 
> $ cat /proc/cpus/0
> 
> PROCESSOR=0
> VENDOR_ID=GenuineIntel
> CPU_FAMILY=6
> MODEL=6
> MODEL_NAME="Celeron (Mendocino)"
> .....
> 
> $ for i in `ls /proc/cpus/` ; do
> 	cat $i
>   done
> ...

much better.  

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

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

[Ben Greear]

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
>>>CPU_FAMILY=6
>>>MODEL=6
>>>MODEL_NAME="Celeron (Mendocino)"
>>>.....
>>>
> 
> PROCESSOR=1


or PROCESSOR1=1

Either way, it's still trivial to parse with perl or c/c++/Java
and probably a dozen other languages I don't know...

Ben


> ...
> 
> 
>>>. /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?
> 
> MfG, JBG
> 
> 


-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

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

[Jan-Benedict Glaw]

On Tue, 2001-11-06 15:46:43 -0700, Ben Greear <greearb@candelatech.com>
wrote in message <3BE86853.9020305@candelatech.com>:
> 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
> >>>CPU_FAMILY=6
> >>>MODEL=6
> >>>MODEL_NAME="Celeron (Mendocino)"
> >>>.....
> >PROCESSOR=1
> or PROCESSOR1=1
> 
> Either way, it's still trivial to parse with perl or c/c++/Java
> and probably a dozen other languages I don't know...

Come on - it's a cludge...

MfG, JBG

-- 
Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481

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

[Martin Dalecki]

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
> > > CPU_FAMILY=6
> > > MODEL=6
> > > MODEL_NAME="Celeron (Mendocino)"
> > > .....
> 
> 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?

<IRONY>
ksh93 arrays 
</IRONY>

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

[J . A . Magallon]

On 20011106 Erik Hensema wrote:
>Stephen Satchell (satch@concentric.net) wrote:
>>The RIGHT tool to fix the problem is the pen, not the coding pad.  I
>>hereby pick up that pen and put forth version 0.0.0.0.0.0.0.0.1 of the
>>Rules of /Proc:
>
>Agreed.
>
>>
>>7)  The /proc data may include comments.  Comments start when an  unescaped 
>>hash character "#" is seen, and end at the next newline \n.  Comments may 
>>appear on a line of data, and the unescaped # shall be treated as end of 
>>data for that line.
>

Well, perhaps this is a stupid idea. But I throw it.
ASCII is good for humans, bin is good to read all info easily in a program.
Lets have both.

Once I thought the solution could be to make /proc entries behave
differently in two scenarios. Lets suppose you could open files in ASCII
or binary mode. An entry opened in ASCII returns printable info and opened
in binary does the binay output. As there is no concept of ASCII or binary
files in low-level file management, the O_DIRECT flag (or any new flag) could
be used.

And (supposing all fies in /proc are 0-sized) perhaps a seek position could be
defined for reading a format string or a set of field names, ie:
lseek(SEEK_FORMAT); read(...);

Same for writing, opening in "wa" allows to write a formatted number (ie,
echo 0xFF42 > /proc/the/fd) and  "wb" allows to write binary data
(write("/proc/the/fd",&myValue)).

Just an idea...

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.14-beo #1 SMP Tue Nov 6 16:23:01 CET 2001 i686