> 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
Remco Post writes:
> 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.
Add something to /proc/*/status between SigIgn and SigCgt.
Stuff breaks because apps that use SigCgt must simply assume
that it comes after SigIgn due to somebody changing the
way SigCgt gets spelled. (it was SigCat maybe)
I'd expect many apps to have stack overflows if you add stuff.
Sure, you could say that's bad user code, but it happens.
For a binary format, you DO NOT need to update user apps any
more than you would for text. I don't see why people think
this is so hard. Let's design a /proc/*/foo file.
#define FOO_PID 0
#define FOO_PPID 1
#define FOO_PGID 2
#define FOO_SIG_IGN 3
#define FOO_FILENAME 4
#define FOO_STATE 5
#define FOO_VM_LOCKED 6
__u64 foo[7];
Now you want to expand things. Fine. If anything goes from 16 bits
to 32 bits, well, we already have padding for it. Suppose Linus
finally sees the light about signals, adding an extra 64. In that
case, we just add FOO_SIG_IGN_HIGH for the top bits and increase
the array size by one. Old apps don't read that and don't care.
The same goes for FOO_FILENAME, with old apps getting truncation
at 8 bytes and new apps getting truncation at 16 bytes. Now maybe
we decide that FOO_STATE is obsolete -- we all have hyperthreaded
processors that handle thousands of threads and nothing ever blocks.
No problem, just have the kernel supply a dummy value to keep the
old apps happy.