>There's been regular comments over the last few months on the above
>topic, with several viewpoints from each side being put forth.
>However, one apparently simple means of allowing BOTH to coexist has
>just occurred to me, and I'd like to ask what's wrong with it before I
>take it any further...
>
>When a program opens a file for input, one of the flags it can set on
>that file is the one indicating whether the file is in RAW or COOKED
>mode. Is there any reason why we couldn't make use of this flag with
>the /proc files, with RAW mode producing results in BINARY format
>ready for direct input to another program, and COOKED mode producing a
>human-readable ASCII output?
I don't know what the original design goals were behind /proc,
but I must say that I agree. I love the information that proc
provides, but I've tried writing some programs to parse some of
the stuff and it is a nightmare. IMHO, it should be easy to
*CODE* stuff firstly. Thus I would favor a binary interface to
/proc myself. Or perhaps a new heirarchy? /binproc? I dunno,
but there are enough problems with parsing /proc that something
should be done.
It seems every new kernel that comes out, /proc/cpuinfo changes
the way it displays and scripts I've written break. Other
programs (not major important ones) have broken as well.
-- Mike A. Harris - Computer Consultant - Linux advocateLinux software galore: http://freshmeat.net
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/