Let me join in this little crusade for the perfect /proc filesystem
layout. :-)
I don't like the proccat idea simply because I can just see users
writing posts to the mailing lists complaining that they can't read the
/proc entries and all. The reason we bad it human readable was because
we could expect "cat" to be on just about any system, and it was pretty
easy to figure out how to view the /proc file entries.
But, I can see how having proccat would be nicer since anyone could view
it how they wanted to.
Why not make /proc system format a kernel option? I.E. put more bloat
in the linux kernel <g>
That's probably not a good idea either since we'll have two /proc file
systems to worry about, and we'd have to worry about breaking
both/either of them. Well, you'd. I'm not a kernel developer, jsut a
spectator. :-)
Is there any way for the kernel to decide how to parse the /proc entries
someone is trying to view in real time? I.E., if proccat is trying to
read it, to parse it so proccat is happy, and if cat is trying to view
it, to make it human readable? Would that slow things down too much?
I've got it! Depending on a kernel option when compiling (or maybe via
lilo), the kernel can either output the /proc entries in proccat format,
or optionally parse them itself if the kernel option is enabled. In
other words, make the kernel store it as the binary format, send it out
as binary format if it needs to. If someone enables the kernel option,
some sort of in-kernel parser can then output the expected
human-readable output. That would make both camps happy, and you would
only have to modify one format when updating proc entries. This would
also keep the format pretty much the same for all /proc entries.
Ben