> As for code maint. and kernel changes breaking things... both happen already
> with the text based system. Binary structures can be constructed to be
> extensible without breaking old tools. Plus, the information exported from
> the kernel (in the case of processes) need not change with every version
> of the kernel.
And the exact same thing can be done with ASCII, too - only easier.
> I don't think people realize just how many CPU cycles are being needlessly
> expended in passing information between the kernel and the user. When I
> have the time, I'll add binary interfaces for various things and show
> exactly how expensive the existing system is -- all for the sake of being
> able to use 'cat' and 'grep'.
I consider those cycles *very* well spent. Being able to use those common
tools is rather important to very many people.
Let's write a /proc ASCII coding rules document. It should document well a
few (*very* few) generic formats to use for new entries, and big fat
warnings about ever changing the format of existing tables, and it should
be easy to find in /Documentation/ - and we should immediately jump on
anyone who violates it without, in advance, discussing the problem he's
trying to solve, and convincing us that they can't be solved any other
way.
I don't much care how those formats look, as long as they're easy to parse
and to extend compatibly, and *few*.
MfG Kai
-
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/