> Evan Jeffrey <ejeffrey@eliot82.wustl.edu> writes:
> > > /proc -> /system/proc
> > > /dev/fd -> /system/fd
> > > /dev/scd0 -> /system/devices/scsi0/target6/lun0
> > People are going to scream bloody murder about that. It breaks a lot of
> > stuff. OTOH, whatever we do to /proc is going to break some stuff.
[SNIPPED]
Let me throw this idea at you.
I think the /proc file system should be designed so that it
can be readily read by machine-specific utilities. Further,
its design should be predicated upon not breaking existing
utilities when a new field in added or new functionality is
provided. Old tools just don't display the new information.
It is convenient that the /proc file-system is human readable,
however its design should not be based upon a person's ability
to read it, but rather upon the ability of a utility to
rapidly parse the available information with a minimum of
overhead.
The format of a display should be left up to the developer of
the utility that uses the /proc file-system information. There
should be no attempt to make the contents of each of the /proc
file-system files "pretty".
Given this, I propose the following standardized format of a
/proc file-system entry.
1.00 A line is defined as an ASCII text string that ends in
a line-feed.
1.01 A line can be up to TBD bytes in length. This length
shall be chosen so that an entire line may be read in one file
read operation.
2.00 The first line shall consist of the names of each of
the subsequent fields.
2.01 These names shall be delimited by a single space.
2.02 Where names would normally have spaces, these spaces
shall be replaced with the underscore character.
2.03 The nature of the fields specified are such that the
text, and the number of fields represented, can be readily
extracted from the string first read from the file, using
readily available 'C' runtime library functions.
2.04 Every field depicted in the header, shall have a
subsequent line of data in the file.
2.05 If a file header contains a field that in not used in
a specific platform, a blank line consisting of a single
space, followed by the line-feed character, shall be used as a
place-holder for that data.
This space is important with some 'C' run-time libraries
because a single line-feed without a preceding space is often
misread.
2.06 Any field that becomes unused or obsolete is renamed
with the single character '?'. Fields may be reused at a later
date if the utilities that use these fields are correctly
written.
2.07 Any utility reading the file header shall ignore any
field consisting of a single '?'. It must also properly
ignore, i.e., skip its subsequent data line.
2.08 Any utility using /proc file-system data must not rely
on a specific field offset. Instead, it must use the field
name. This requirement, in fact, implements 2.07 as a side
effect.
2.09 Any utility using /proc file-system data shall
properly handle any missing fields. This handling may range
from quietly ignoring missing data, to exiting after a hard
error message. In no case shall the utility crash, i.e., seg-
fault if there are missing fields.
Here is the existing entry for /proc/cpuinfo.
processor : 0
cpu : 586
model : Pentium 75+
vendor_id : GenuineIntel
stepping : 12
fdiv_bug : no
hlt_bug : no
fpu : yes
fpu_exception : yes
cpuid : yes
wp : yes
flags : fpu vme de pse tsc msr mce cx8 apic
bogomips : 66.36
processor : 1
cpu : 586
model : Pentium 75+
vendor_id : GenuineIntel
stepping : 12
fdiv_bug : no
hlt_bug : no
fpu : yes
fpu_exception : yes
cpuid : yes
wp : yes
flags : fpu vme de pse tsc msr mce cx8 apic
bogomips : 66.36
My proposal would change this to:
Ignore the fact that this editor will put in a line-feed after
every line of text.
processor cpu model vendor_id stepping fdiv_bug hlt_bug fpu
fpu_exception cpuid wp flags bogomips processor cpu model
vendor_id stepping fdiv_bug hlt_bug fpu fpu_exception cpuid wp
flags bogomips
1
586
Pentium 75+
GenuineIntel
12
no
no
yes
yes
yes
yes
fpu vme de pse tsc msr mce cx8 apic
66.36
2
586
Pentium 75+
GenuineIntel
12
no
no
yes
yes
yes
yes
fpu vme de pse tsc msr mce cx8 apic
66.36
Now, this isn't pretty. But it parses easily. Even if you do
everything without sscanf() and friends, we readily have the
following information after the first file read.
o The number of data elements. (The number of characters
with the value of 0x20 or below).
o The names of the data elements and any to be ignored or
skipped.
Cheers,
Dick Johnson
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Richard B. Johnson
Project Engineer
Analogic Corporation
Voice : (508) 977-3000 ext. 3754
Fax : (508) 532-6097
Modem : (508) 977-6870
Ftp : ftp@boneserver.analogic.com
Email : rjohnson@analogic.com, johnson@analogic.com
Penguin : Linux version 2.1.34 on an i586 machine (66.15 BogoMips).
Warning : I read unsolicited mail for $350.00 per hour. Supply billing address.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-