Basically, /proc files were supposed to be read by 'cat' and nothing more.
Explicit programs to read and interprete the output of the files in proc
seem a complete waste and overkill to me. Consider this: The kernel does a
hard job providing some virtual fs, he forms all his internal binary data
into ascii strings.
To avoid buffering problems you cannot always read a /proc file
atomically, which is also a source for problems.
Then, the user mode application does a hard job to ensure it gets a
somehow consistent state, it parses the ascii info into binary, outputs it
in another ASCII form again..
Well, I only see overhead, overhead, overhead, overhead and wasted
(because duplicated) work of the authors of the /proc drivers as well as
the authors of the interpreting utilities.
And now you even want to have an ioctl() to get some binary info?
Honestly, I'd say. Simply add ONE new syscall like:
int system_info(char *what, void *data, size_t alloc_len);
there you can pass well known strings to what ("memory", "devices", etc).
(maybe even #define'd ints, but strings seem more easy to maintain to me)
and get a WELL DOCUMENTED binary structure back.
And then forget at least about all these /proc info files which just
duplicate ordinary Unix commands like 'route', 'ifconfig', 'ps'. I
mean, it is nice that we showed to the world that it can be done. But now
lets get serious.
Also, don't tell me: Oh, but the ASCII files are more readable and you
don't need a new utility when the info in the file changes. Anyone
remember the zillions of 'my pentium got the FPU flu/has the FPU bug'
posts when procps needed an update? Ok, good.
Admittedly, it is a powerful feature that you can mmap or reopen files
of other processes by use of /proc. This applications makes sense (and
is obviously why /proc is named /proc not /sys_stat).
But it also opens up quite some possible security problems. People with
really mission critical stuff may want to get rid of /proc but still have
a working 'ps'. Also, it is nice if you can get a quick overview about a
few params like /proc/cpuinfo and such, even when you don't have the
special client.
But when you don't have a working 'route' or 'ifconfig' utility fitting to
your kernel version, you also don't need to know what the current state of
these kernel subsystems is. You can't use them anyway.
All this IMHO /proc insanity (because going over the spot) started with
procps. kmem-ps is a hack, sure, but I wonder that noone ever had the idea
to add such a sys call which passes a binary, cooked down process table to
user mode. And consider the simplicity of a single function pointer, where
any kernel part can hook a handler into the system_info syscall to check
for its "what" parameter (I know, you need a linked list s.t. handler can
easily be removed). How simple and efficient would this be compared to
/proc ?
Well, anyway, now we have /proc and have to live with it and we showed the
world how powerful linux and its authors are that they are able to write
so many virtual files.
But now: An ioctl() on /proc to get the binary data. Sorry, but for my
taste, this is the final drop in the barrel. This is just too much.
Michael.
(eowmob@exp-math.uni-essen.de or eowmob@pollux.exp-math.uni-essen.de
Please do not use my vm or de0hrz1a accounts anymore. In case of real
problems reaching me try mat42b@spi.power.uni-essen.de instead.)