One problem that has reared its ugly head is reading newer format proc
entries with older programs. The current plain text /proc files are not
suited to easy upgrades. It is difficult enough to add a field at the end of
an existing line, often user mode utilities will break. Adding a field to
the middle is just not possible without some form of tagged text. I know the
standard response is "well if you upgrade the kernel you just have to upgrade
your utilities as well" but how many problems have we seen because this just
does not happen?
I would like to see a clean break to tagged text for *all* proc files. That
way we only get caught once when the change is made, thereafter user mode
utilities will simply ignore /proc fields they do not recognise, making for a
much cleaner upgrade path.
The other problem that needs to be addressed in /proc is handling output of
more than 4K. The only indication the procinfo routine gets is the "offset"
into the generated output, the procinfo code is expected to somehow
reposition itself and pick up where it left off. Since the underlying tables
are continually changing, this suffers from race conditions. Some of the
work arounds are not very nice.
It does not seem possible to cleanly restart procinfo output with the current
calling sequence. We come close but it is not perfect. I suggest that the
driver be modified to pass a 4K page, if that is too small then instead of
doing it in chunks with races, the procinfo routine returns a code saying
"buffer too small". The proc driver then passes larger and larger buffers
until the procinfo routine has enough space to display all the data in one
go. Once the data has been generated, the driver can copy to user space in
page chucks. High water marks would be saved for each procinfo routine that
needed more than 4K (a small chain owned by the driver) so the algorithm
would quickly discover how much space each procinfo routine needed.
Keith Owens