"We do not want to make changes to procfs that affect programs already written."

This is the same excuse used often by Microsoft in their braindamaged designs.

Further, if the design of procfs had been made with forward compatibility in mind, this would not be a problem now. Unfortunately, developers continue to haphazardly slap together additions to procfs with complete disregard for issues like standard data formats, or multiple architectures. Part of this is due to the fact that there are simply no set standards for programmers to follow.

Documentation? Several developers have referred to some vapor-ish document with "procfs standards". Who wrote it? Where can I get it? Nobody has been able to tell me where this document actually exists.

If there was any time to establish standards, it is now.

BTW, I don't know if anyone has noticed -- programs have changed and continue to change throughout the 2.1.x kernel development cycle. mount, binutils, ifconfig, modutils, nfs have changed. Therefore, the backward compatibility excuse becomes doubly null and void.

The differences between output for /proc/devices, /proc/modules, /proc/locks and /proc/pci is only a small example. Sometimes there are spaces, sometimes tabs. Sometimes there are colons, sometimes not. Sometimes there are headers, sometimes not. Data is in hex, decimal, zero padded, unpadded, column aligned, unaligned and just about every possible combination of all of the above. I even seem to recall seeing some octal somewhere. It's enough to send a programmer into convulsions.

Here's output from /proc/cpuinfo on a DEC UDB:

cpu                     : Alpha
cpu model               : LCA4
cpu variation           : -4294967301
cpu revision            : 0
cpu serial number       : Linux_is_Great!
system type             : Noname
system variation        : 0
system revision         : 0
system serial number    : MILO-0000
cycle frequency [Hz]    : 0
timer frequency [Hz]    : 1024.00
page size [bytes]       : 8192
phys. address bits      : 34
max. addr. space #      : 63
BogoMIPS                : 163.57
kernel unaligned acc    : 0 (pc=0,va=0)
user unaligned acc      : 1897470 (pc=12015a51c,va=1204eaf78)

And here's the output on an x86:

processor       : 0
cpu             : 586
model           : Pentium 75+
vendor_id       : GenuineIntel
stepping        : 4
fdiv_bug        : no
hlt_bug         : no
fpu             : yes
fpu_exception   : yes
cpuid           : yes
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8
bogomips        : 35.84

And here's the output from Sparc:

cpu             : Fujitsu  MB86900/1A or LSI L64831 SparcKIT-40
fpu             : Weitek WTL3170/2
promlib : Version 2 Revision 2
prom            : 2.4
type            : sun4c
ncpus probed    : 1
ncpus active    : 1
BogoMips        : 24.88
vacsize : 65536 bytes
vachwflush      : no
vaclinesize     : 16 bytes
mmuctxs : 8
mmupsegs        : 128
kernelpsegs     : 32
kfreepsegs      : 0
usedpsegs       : 62
ufreepsegs      : 0
user_taken      : 0
max_taken       : 21
context : 637 flushes
segment : 114285 flushes
page            : 232086 flushes

And another Sparc:

cpu             : Texas Instruments, Inc. - MicroSparc
fpu             : TI MicroSparc on chip FPU
promlib         : Version 3 Revision 2
type            : sun4m
Elf Support     : yes
BogoMips        : 49.86
MMU type        : TI Tsunami
invall          : 42
invmm           : 302597
invrnge         : 3754925
invpg           : 4323419
contexts        : 64
big_chunks      : 0
little_chunks   : 0

And the output from PowerMac:

100MHz PowerPC 601 rev 0.2

Does any of this make sense?

Why put multiple CPUs in /proc/cpuinfo when it's not done that way for multiple adaptors in /proc/scsi? For example, here's the structure of the scsi directory:

/proc/scsi/aic7xxx/0
/proc/scsi/aic7xxx/1
/proc/scsi/aic7xxx/...
/proc/scsi/scsi

While /proc/cpuinfo tries to cram the output from all the available CPUs into one entry. Doesn't something like this make more sense:

/proc/cpu/0
/proc/cpu/1
/proc/cpu/...

If there is /proc/scsi, where is /proc/ide? There is at least as much useful information to be gleaned from ide devices as there is from scsi, yet this entry is mysteriously missing.