Linus Torvalds wrote:
>
> In article <8725685E.007519CF.00@d53mta03h.boulder.ibm.com>,
> <breed@almaden.ibm.com> wrote:
> >
> >I wrote an wireless ethernet driver awhile ago
> >(http://www.cse.ucsc.edu/~breed/airo.html) and found the /proc interface to
> >be an extremely useful interface to the many knobs in the card. I am a bit
> >uncomfortable defining my own namespace in the /proc file system (did it
> >anyway:) and I've been wondering for a while if there are guidelines
> >somewhere on where things should go. I would really like to tap into an
> >existing directory for ethX for example...
>
> The thing to do is to create a
>
> /proc/drivers/<drivername>/
>
> directory. The /proc/drivers/ directory is already there, so you'd
> basically do something like
>
> create_proc_info_entry("driver/mydriver/status", 0, NULL, mydriver_status_read);
>
> to create a "status" file (etc etc).
>
> >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.
>
> 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).
Are you just blind to the neverending format/compatiblity/parsing/performance
problems the whole idea behing /proc induces inherently?
Oh yes they don't turn up that frequently anylonger, since
everybody learned in the time between don't touching anything there
like a heap of shit. Instead of changing something, one leaves the
broken /proc interface where it is and adds just another new file
(or even dir) there.
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
/proc/ide
/proc/ide/drivers
/proc/ide/hdd
/proc/ide/ide1
/proc/ide/ide1/hdd
/proc/ide/ide1/hdd/capacity
/proc/ide/ide1/hdd/settings
/proc/ide/ide1/hdd/model
/proc/ide/ide1/hdd/media
/proc/ide/ide1/hdd/identify
/proc/ide/ide1/hdd/driver
/proc/ide/ide1/model
/proc/ide/ide1/mate
/proc/ide/ide1/config
/proc/ide/ide1/channel
/proc/ide/hda
/proc/ide/ide0
/proc/ide/ide0/hda
/proc/ide/ide0/hda/smart_thresholds
/proc/ide/ide0/hda/smart_values
/proc/ide/ide0/hda/geometry
/proc/ide/ide0/hda/cache
/proc/ide/ide0/hda/capacity
/proc/ide/ide0/hda/settings
/proc/ide/ide0/hda/model
/proc/ide/ide0/hda/media
/proc/ide/ide0/hda/identify
/proc/ide/ide0/hda/driver
/proc/ide/ide0/model
/proc/ide/ide0/mate
/proc/ide/ide0/config
/proc/ide/ide0/channel
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:
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
*
***
*****
*******
*********
***
***
***
***
***
***
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:
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!
You's sincerly:
root@localhost"
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
--Marcin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:08 EST