Including typing info with the data itself, which is an entirely different
matter than using C types internally ( to produce text or other output),
could have several effects. Assuming the type field gives the size of the
net datum, everything (each /proc "file") is then a traverseable list.
Platform differences in C types can be rectified at read-time. Endianism
is a single platform constant. (Maybe /proc should be /corp on Intels :o)
This involves a /proc-specific data type scheme. Or rather, it involves
promoting a data typing scheme for /proc to be readable by anything. In a
Forth-like language I poke at finishing now and then, there are 3 data
types, 2 of which may pertain here. There are addresses and pytes. A pyte
is an "int" of 1, 2, 4, 8, 16 ... or 256 bytes. Pytes are handy. They make
stuff like 16 bit characters potentially a drop-in.
/proc/kmem is externally sized, by the filesystem. ls -l shows an overall
size for the file. This is real handy for parsing a list of binary data.
Say a /proc type is a byte, a pyte is type 01, and a pyte size is a byte
expressing the pyte size as a power of 2. Then for a /proc namespace
entity of known ovarall size, with endianism known, and a byte of net data
is shown here as "XX", then a bunch of e.g. IP addresses would look like
01 02 XX XX XX XX 01 02 XX XX XX XX 01 02 XX XX XX XX.....
in bpe or od or whatever. Beyond the above info, description strings and
so on, something analagous to a header file might be of service. In
userland. Proc.Map perhaps.
F W I W.
Rick Hohensee http://cqi.com/~humbubba
colorg on EFnet IRC #linux chanop
cLIeNUX xart kandinski cycluphonics ratioles Md., USA
This is your brain on colorg --> (@#*%@#() <---~~~_()()(
Any questions?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/