> Indeed; we can only do this once; I'm also not convinced, by the way,
> that the current scheme of /proc/<major subsystem> isn't the best way to
> go. If I'm trying to look at network related things, it's actually much
> easier if everything is under /proc/net, than if things are scattered
> all over hell-and-gone.
Ted,
I am not saying that the present scheme is a bad
thing, just that it isn't being standardised. I have been
toying around with the -rough- scheme below.
( note, I've removed the 'dev' directory idea ;-)
/proc/audio < soundblasters,midi,...
/proc/bus < isa,eisa,vme,sbus,pci,std,vlb,...
/proc/tty < terminal-sess.s,... you've already done.
/proc/cpu < cpu's.. ? already present as file cpuinfo
/proc/graphics (video ?)
/proc/io
/proc/keyboard
/proc/memory < meminfo, ramdisks, ...
/proc/parallel
/proc/pointing
/proc/net < already present as a directory
/proc/serial
/proc/storage
/proc/dev < already present as file devinfo
These are just an idea, I need help along the way to get
what is needed in & what is just useless removed, from this
idea. And also if the idea has -any- merit.
What I see is a decent tool for helping new (& experienced) users
diagnose troubles that they are seeing, And getting decent info
about what each of our systems look like to the kernel.
What is needed is a reasonable format to the directories & files
they contain & maybe what minimum info should be in the files .
> Likewise, I'm in the middle of creating /proc/tty, which will contain
> tty-related information, both hardware drivers and tty line discplines.
See above...
> And, it's pretty obvious that if I'm interesting in something related to
> the SCSI system, I should look in /proc/scsi.
OK, just grand. ;-)
Now try this on for size.
the ncr53c8xx scsi driver, you'll see that there is info here
that isn't seen readily, that there are 2 scsi controllers here.
When you do a 'ls' on the directory of the name of the driver.
Even then you'd still not be sure what info is in there without
'cat'ng the files 0 & 1.
ls /proc/scsi
ncr53c8xx/ scsi
ls /proc/scsi/ncr53c8xx
0 1
'cat'ng the file scsi gets you all your disks/tapes/cdroms.....
cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: SEAGATE Model: ST11200N Rev: 3124
Type: Direct-Access ANSI SCSI revision: 02
...snip...
Host: scsi1 Channel: 00 Id: 06 Lun: 00
Vendor: PIONEER Model: CD-ROM DR-124X Rev: 1.06
Type: CD-ROM ANSI SCSI revision: 02
What I'm trying to do is this (using above as example)
if there are 2 scsi controllers then
ls /proc/scsi
scsi0
scsi1
inside these directories would be
ls /proc/scsi/scsi0
Controller < containing particular info on controller 0,
0 <-OR, Its driver & ver.
disk0 < containing particular info on first disk on this controller
tape0 < .....
...0-99
> I'm not convinced that taking parts of /proc/net, /proc/scsi, and
> /proc/tty, and mashing them all under /proc/dev is necessary progress.
> It may look good from an Computer Science professor's point of view, but
> is it really the most convenient way for us to organize the information,
> and does it make things easier for a user who is trying to navigate
> through the proc filesystem?
This is -not- my plan or idea presently, as you can see .
Alex said whatever I came up with -could not- conflict with
what was/is already in /proc, this is where the 'dev' directory
idea sprang from.
What I am hoping for is a decently intuitive interface to /proc,
just with some definative content.
I am not a 'Computer Science professor' nor will I ever be. ;-}
But, I am a resonably competent person with a hope to be
allowed to manuever the /proc directory into a -very usable-
format. Along the way I need & want all the help I can get
to this end.
PS: OK, Tear it up ;-)), But also Please give pointers & suggestions
while shreading.
Tia, JimL
_________________________________________
| James W. Laferriere | Network Engineer |
| babydr@nwrain.net | System Techniques |
| 25416 - 22nd S. | Kent, WA 98032 |
| Give me VMS -or- Give me Linux |
| but only on AXP |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
My libraries & programs status ( most are here now )
At the time of this writing, I am using.
Linux-2.0.29 , eepro100.c/ v0.24 30/01/97 in kernel.
, ncr53c8xx.c/ v1.14c 08/11/96 in kernel.
Gcc v. 2.7.2 ; binutils-2.6.0.14 ; sysvinit-2.62
ld.so.1.7.14 ; libc.so.5.3.12 ; libc.so.4.7.6
libg++.so.27.1.4 ;
proc-ps 0.99 ; net-tools 1.2.0 ; mount-2.5j
Modules 2.0.0 ; loadkeys 0.89 ;
--- Linux-Vax Port, Still in Progress . IE: No Progress To Report. ;-) ---
I still think a structure that has as its base 'dev' or
another less confusing name & then the lower structures,
will help keep it out of the way of the present scheme.
/proc
/proc/dev < This name needs further examination.
/proc/audio < soundblasters,midi,...
/proc/bus < isa,eisa,vme,sbus,pci,std,vlb,...
/proc/tty < terminal-sess.s,...
/proc/cpu < cpu's.. ? already present as a file
/proc/graphics (video ?)
/proc/io
/proc/keyboard
/proc/memory < meminfo, ramdisks, already present as a file
/proc/parallel
/proc/pointing
/proc/net < see below. #1 already present as a file
/proc/serial
/proc/storage < see below. #2
/proc/dev < already present as a file
#1 >
> /proc/net/'devname' | = *
> /proc/net/ * /atm |
> /proc/net/ * /10b |
> /proc/net/ * /100b |
> /proc/net/ * /gigabit |
> /proc/net/ * /serial |
> /proc/net/ * /tokenring |
> /proc/net/ ** /protocol/appletalk
> /proc/net/ ** /protocol/ax25
> /proc/net/ ** /protocol/bridge
> /proc/net/ ** /protocol/decnet
> /proc/net/ ** /protocol/framerelay
> /proc/net/ ** /protocol/hdlc
> /proc/net/ ** /protocol/ipv4
> /proc/net/ ** /protocol/ipv6
> /proc/net/ ** /protocol/ipx
> /proc/net/ ** /protocol/ppp
> /proc/net/ ** /protocol/slip
#2 >
> /proc/dev/ide
> /proc/dev/mscp ( for my vax port ... ;-)
> /proc/dev/scsi
> /proc/dev/smd