[lkml]   [2001]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] 2.5 PROPOSAL: Replacement for current /proc of shit.
In message <> 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.

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:12    [W:0.112 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site