In message <20011105033316Z16051-18972+45@humbolt.nl.linux.org> you write:
> Yes, sold, if implementing the formatter is part of the plan.
>
> Caveat: by profiling I've found that file ops on proc functions are already
> eating a significant amount of cpu, going to one-value-per-file is going to
> make that worse. But maybe this doesn't bother you.
What concerns me most is the pain involved in writing a /proc or
sysctl interface in the kernel today. Take kernel/module.c's
get_ksyms_list as a typical example: 45 lines of code to perform a
very trivial task. And this code is sitting in your kernel whether
proc is enabled or not. Now, I'm a huge Al Viro fan, but his proposed
improvements are in the wrong direction, IMHO.
My first priority is to have the most fool-proof possible inner kernel
interface. Second is trying to preserve some of the /proc features
which actually work well when correctness isn't a huge issue (such as
"give me everything in one table"). Efficiency of getting these
things out of the kernel is a distant last (by see my previous comment
on adapting sysctl(2)).
I'd like to see /proc (/proc/sys) FINALLY live up to its promise
(rich, logical, complete) in 2.5. We can do this by making it the
simplest option for coders and users.
Rusty.
-- Premature optmztion is rt of all evl. --DK - 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/
This archive was generated by hypermail 2b29 : Wed Nov 07 2001 - 21:00:28 EST