> Is this requirement neccessary for the kernel or for user-level
> programs? The file format that I proposed is very simple/fast for
> creating (this is, what the kernel would usually do),
No, it is very slow for generation, cause the Kernel must be possible to
SKIP entries. This means if u read 1k from the proc-file and then another 1k
the Kernel has to figure out which entries will start at the second k.
Normally the Kernel will generate the first 1k lines and throw the away,
only to find the matching record. Alan modified this, that every line is
128bytes long. Therefore the KErnel knows that if u start reading at
byteposition 500, that u can skip generating the first 3 records. The
records are still generated in "%s %s %s" style, put the lines are padded
with blanks. Just look at /proc/net/route for a example in recent kernels.
Programs that read /proc files should therefore try to read as much as
possible into buffers. (hmm.. another change to the net-tools :).
> but it
> admittedly requires some extra parsing for evaluating (that is what
> user level programs would usually do). If you need to do this fast,
> you could try to go with flex/yacc, which often gives acceptable
> performance.
No, fscanf is faster I think. The 'blank' delimeter style is human readable
AND computerparseable (as long as there are no blanks in.. programnames :)
> If this is not an option, and you insist on having fixed
> width records, we will have to come up with some extensions to the file
> format --- even though, that will either limit versatility or require
> us to accept special cased file-formats.
Alans fixed records are fully backward compatible. I dont see the need for
tagged /proc Files at all. If we need a tag, then we need it in the title of
the /proc file. I have used the Title lines a few times to figure out which
Informations are stored in the /proc File. This is based on my experience
with the net-tools (which is reading quite a few /proc/net/ files.
Greetings
Bernd
--
(OO) -- Bernd_Eckenfels@Wittumstrasse13.76646Bruchsal.de --
( .. ) ecki@lina.{inka.de,ka.sub.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD eckes@irc +4972573817 *plush*
(O____O) If privacy is outlawed only Outlaws have privacy