Re: PROPOSAL: /proc standards (was dot-proc interface [was: /proc

[Remco Post]

> 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. [phone]    Fax. [phone]

"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