Messages in this thread |  | | From | Remco Post <> | Subject | Re: PROPOSAL: /proc standards (was dot-proc interface [was: /proc | Date | Wed, 07 Nov 2001 13:35:14 +0100 |
| |
> On Tue, 6 Nov 2001, Roy Sigurd Karlsbakk wrote: > >What about adding a separate choice in the kernel config to allow for > >/hproc (or something) human readable /proc file system? > > Just think about it for a minute. > > There are three ways to address "/proc": > - 100% binary interface > * human interaction doesn't belong in the kernel - period. > - optimally formated text > * not designed for humans, but in human format ("text") > - human readable > * thus the entire OS is reduced to "cat" and "echo" > > Providing more than one interface/format means code duplication. It doesn't > matter how much is actually compiled. Someone has to write it. Others have > to maintain it. Suddenly a change in one place becomes a change in dozens > of places. > > Personally, I vote for a 100% binary interface. (no surprise there.) It > makes things in kernel land so much cleaner, faster, and smaller. Yes, > it increases the demands on userland to some degree. However, printf/scanf > is one hell of a lot more wasteful than a simple mov. > > For my worst case scenerio, answer this: > How do you tell how many processors are in a Linux box? > > The kernel already knows this, but it isn't exposed to userland. So, one > must resort to ass-backward, stupid shit like counting entries in > /proc/cpuinfo. And to make things even worse, the format is different for > every arch! (I've been bitching about this for four (4) years.) > > And for those misguided people who think processing text is faster than > binary, you're idiots. The values start out as binary, get converted to > text, copied to the user, and then converted back to binary. How the hell > is that faster than copying the original binary value? (Answer: it isn't.) > > And those who *will* complain that binary structures are hard to work with, > (you're idiots too :-)) a struct is far easier to deal with than text > processing, esp. for anyone who knows what they are doing. Yes, changes > to the struct do tend to break applications, but the same thing happens > to text based inputs as well. Perhaps some of you will remember the stink > that arose when the layout of /proc/meminfo changed (and broke, basically, > everything.) > > --Ricky >
Hi,
the nice thing about text interface as opposed to a struct is that the userland can parse a "CPU_FAMILY=6" as good as 0x6, but if you decide to change the format of the /proc entry, with a binary interface, this means you MUST update the userland as well, while with a text interface and some trivial error processing, adding a field would in the worst case mean that the userland app will not profit from the new info, but it will NOT BREAK.
I do realize this means that the userland apps have to be carefully designed and implemented, but at least, a kernel upgrade wouldn't imply an upgrade of half the OS tools. Once programmers start to realize that error processing is a must anyway, this is a trivial step (and no, "Your proc is broken, go fix it" messages are not error processing ;).
-- Met vriendelijke groeten,
Remco Post
SARA - Stichting Academisch Rekencentrum Amsterdam High Performance Computing Tel. +31 20 592 8008 Fax. +31 20 668 3167
"I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much of course - the computer industry didn't even foresee that the century was going to end." -- Douglas Adams
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |