> On Wed, 16 Apr 1997, Richard B. Johnson wrote:
[SNIPPED out my stuff]
>
> Each line shall consist of three parts
> <name><arbartray whitespace><": " or ":: "><value>
>
> name: There should be no reapeats for names within any single procfile (file
> under /proc). (If you would have one, consider creating a subdirectory).
> Names should be parsed case-sensitive, and may only contain printable,
> non-whitespace, non-colon chararactars.
>
> arbartray whitespace: Any sequence of the charaters " ", and " " (space and
> tab). This should be ignored during parseing, and during output it is
> recomended that LEN(name)+LEN(whitespace) is constant throughout the
> procfile. Also, it is recomended that tabs are not used. Parsers should
> note that a length of zero (no whitespace) is valid.
>
> ": " or ":: ": Delimits the name+whitespace from the value. A double colon
> serves to note that the feild should be considered unstable, that is, likely
> to have its content redifined or be removed entirely.
>
> value: The value of the entry. Numbers should be written in decimal or in
> MSB left hexidecimal, prefixed with an "0x". Strings may be output with
> standard C style escapes, but shoudn't have any controll characters in them.
> Boolean values should be expresed as yes/no, not on/off, nor true/false.
>
>
> > Here is the existing entry for /proc/cpuinfo, quoted with ">" characters.
> Here is my updated version.
> >
> > processor : 0
> processor :: 0
> Double-coloned since /proc/cpuinfo becomes /proc/cpu/#, with /proc/cpuinfo
> being a symlink to /proc/cpu/0 on uniprocessor boxes only, since a field
> name must uniquly identify a field within a file, so if the program wants to
> know about all of the processors, reading /proc/cpuinfo is not the way to do
> it, but rather stepping through the files in /proc/cpu, in which case you
> allready know the CPU's ordinal.
>
> > cpu : 586
> cpu : 586
> > model : Pentium 75+
> model : Pentium 75+
> > vendor_id : GenuineIntel
> vendor_id : GenuineIntel
> > stepping : 12
> stepping : 12
> > fdiv_bug : no
> fdiv_bug : no
> > hlt_bug : no
> hlt_bug : no
> > fpu : yes
> fpu : yes
> > fpu_exception : yes
> fpu_exception : yes
> > cpuid : yes
> cpuid : yes
> > wp : yes
> wp : yes
> > flags : fpu vme de pse tsc msr mce cx8 apic
> flags :: fpu vme de pse tsc msr mce cx8 apic
> Double-coloned since I would add a feild for each flag with a yes/no, to
> minimize parsing.
> > bogomips : 66.36
> bogomips : 66.36
> --EOF--
> Mine is quite a bit more pretty, and only slightly less pretty. I think
> though, even if you through away the rest, you should keep the
> no-repeated-names rule (important for position-independent parseing, since
> otherwise, there is no unique index key), and the format rules for values
> ("0x"ed hex, MSB first, yes/no bools).
>
> --- James Mastros
>
Okay, now you are talking about making a standard that will allow the
entries to be parsed with <don't flame me> obsolete Unix tools
like `ed` `cut`, etc. This would certainly be useful, but do you want
to design the specification around this?
Look at the other end of the spectrum. The /proc file system on the
Suns can not be read with anything except specialized tools.
My guess is that this discussion will go no where because everyone
has their own idea (rightfully so) of what is best. Hopefully, at
the very least, some kind of consistancy will come out of this.
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.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-