> I'd much rather move to a model in which userspace *explicitly* tells > the kernel which fields it wants, with the kernel replying with just > those particular fields, maybe in their raw binary representations. > The ASCII-text bag-of-everything files would remain available for > ad-hoc and non-performance critical use, but programs that cared about > performance would have an efficient bypass. One concrete approach is > to let users open up today's proc files and, instead of read(2)ing a > text blob, use an ioctl to retrieve specified and targeted information > of the sort that would normally be encoded in the text blob. Because > callers would open the same file when using either the text or binary > interfaces, little would have to change, and it'd be easy to implement > fallbacks when a particular system doesn't support a particular > fast-path ioctl.
You've just reinvented systems calls. I suspect the DB in question cares about CPU related numbers and nothing else which can be nicely split from the rest of /proc/stat.
