Messages in this thread |  | | Date | Tue, 18 Feb 1997 18:18:37 +0100 (MEZ) | From | Michael Weller <> | Subject | Re: Machine friendly format for /proc files |
| |
Sorry, but I can't keep it for myself now anymore. I follow this threat now for a while, but all these machine friendly issues for /proc seem kinda weird to me.
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.)
|  |