Taken from http://kt.linuxcare.com/latest.epl on 2/3/2000, this is just one example of serious design problems with Linux, and serious questions about its present and future direction, considering the plans laid out by its creator. Apparently speed and efficiency aren't as important to Linus as having a pretty filesystemish interface. Hope you didn't want to do anything useful with your CPU in userspace...
Benjamin Reed wrote a wireless ethernet driver that used /proc as its interface. But he was a little uncomfortable defining his own namespace under /proc, and asked if there were any conventions he should follow. He added, "And finally, what's up with sysctl? Are driver writers recommended to use that over extending /proc or is it deprecated? Again guide lines would be nice."
Linus replied with:
directory. The /proc/drivers/ directory is already there, so you'd basically do something like
to create a "status" file (etc etc).
create_proc_info_entry("driver/mydriver/status", 0, NULL, mydriver_status_read);
For the sysctl question, he added, "sysctl is deprecated. It's useful in one way only: it has some nice functions that can be used to add a block of /proc names. However, it has other downsides (allocating silly numbers etc - there should be no need for that, considering that the /proc namespace is alreayd a perfectly good namespace)."
Marcin Dalecki flamed Linus:
My favorite examples for how broken they are
/proc/stat the information there is entierly *broken* misleading and incomplete. (leftover from early days.) /proc/pci static data continuously reconstructed on the fly. (binary to string and then back string to binray in userland...) And now (2.3.xx) it's event binary only... /proc/cpuinfo same here static data. uname is since the beginnging the proper interface for this stuff. /proc/ksyms entierly redundant and not used by the modutils. /proc/modules entierly redundant to the module syscalls. *Not* used by lsmod. /proc/version entierly static data with no apparent value /proc/kmsg entierly redundant to syslog.
One could continue with no end...
root:/proc# cat meminfo
total: used: free: shared: buffers: cached:
Mem: 64577536 62787584 1789952 20643840 1339392 17186816
Swap: 139821056 36478976 103342080
MemTotal: 63064 kB
MemFree: 1748 kB
MemShared: 20160 kB
Buffers: 1308 kB
Cached: 16784 kB
SwapTotal: 136544 kB
SwapFree: 100920 kB
Wonderfull!!!! The same data twice, albeit no one of them easly parsed! Easly parsed? By what? AWK? SED? or should the procps utilities beeing implemented in damn PERL? (Some loosers who don't know C would apreciate this, certainly) !!!!! The only thing I'm missing is adding floating point formats to this...
And then there is the phenomenon of proliferation of /proc items. Just an example...
root:/proc/ide# find /proc/ide
Hell only God know's what they are good for! And there is no userland tool for this. This is the last thing Mark Lord added before ditching ide developement.
root:/proc/sys# find /proc/sys | wc
208 208 7305
Don't tell me any sane admit will fiddle with ALL this... And in esp. any sane system doesn't need this degree of pseudo configuration flexibility.
And here my ABSOLUTE FAVORITE:
Yes reading files, walking dirtrees and parsig them is indeed very very time consuming. I would like to know how well this design will scale to an enterprise server with 32 CPU and X*10000 concurrent processes:PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 21821 root 19 0 1032 1032 816 R 0 4.7 1.6 0:00 top * *** ***** ******* ********* *** *** *** *** *** ***
user:~/mysweethome: Message from root@localhost to user@localhost resived... BLAH BLAH: "Please stop any intensive intermittient computational activity. Due to maintainance work I'm going to run ps auxw int 5 minutes. Thank's in advance for your understanding!Oh don't tell me procps could have been done better, there where years of time for this and apparently nobody managed to get it right for practical reaons..
I think you don't write enough user-land code... (just a guess) go and just compare for example the ps/netstat utlities from *BSD just too see WHY /proc as it is, is a BAD design :-).
Maybe it appears cute as an idea to have something like this, but in practice something like this is inevitable going to result in a coding mess in esp. in an such uncoordinated effort like Linux.
And I didn't even tell a word about the bloat/mess/races inside the kernel code caused by this all...
Really man sysctl *is* much much saner and what should be "depricated" is /proc
There was a bit of discussion, but Linus did not reply.
Alexander Viro replied to Linus' statement that sysctl was deprecated. He burst out with:
What _is_ bogus is the idea of sysctl() doing more than read/write access to constant-sized variables. Or procfs entries doing ioctl(), for that matter - just look at /proc/mtrr, for one specimen.
sysctl() is a perfectly reasonable subset of pseudofs-type stuff, with well-defined semantics (unlike the rest ;-/). The rest is pretty much a maze of twisted little formats, none alike. IMO dissolving the thing is _not_ a good idea. You have the final word, indeed, but I think that sysctlbyname() may remove most of the problems.
Linus replied that he'd accept a patch to turn sysctl into a proc-only thing. He added, "The current problem is that sysclt tries to be more than proc, and has its own name-space etc. Not worth it." Andi Kleen proposed, "The nice thing of giving up the sysctl numbers is that it would be possible to use some ELF section based scheme for declaring sysctl variables in nice wrapper macros. You could get a sysctl variable with a single declaration. This would make them a lot more easy. Would you accept a patch for that?" Linus replied, "Show me the patch, and I can consider it. It would certainly be nicer than what it is now (the include/linux/sysctl.h file is EVIL, and a perfect example of the kind of idiotic brokenness we used to have in /proc before it was cleaned up)."
Theodore Y. Ts'o also replied to Alexander, saying, "I actually like the original sysctl() design --- including the use of reserved numbers. After all, we have system calls, and we don't try to look up system calls when we executed them by name..... why is this OK for system calls, but not OK for sysctl()?" Linus replied:
And system calls are not clearly "hierarchical".
And system calls are supposed to be there regardless of what software and hardware configuration we have there.
In contrast, sysctl isn't all that performance-sensitive, AND they are extremely hierarchical, AND they depend on configuration and timing.
In short, sysctl NEEDS:
In short, you NEED a filesystem. You need to be able to "ls" the thing. You need to be able to search the thing. You need to be doing all the things you can do with a real filesystem.
And flattening it out and trying to number it does not work. Never has, never will. It's not an enumerated space.
|Wed Jan 14 04:08:53 PST 2004||linux/stupidity.src||Updated: Sun Jul 28 2002 22:00.44||Viewed: never|