> 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/
This archive was generated by hypermail 2b29 : Wed Nov 07 2001 - 21:00:34 EST