[lkml]   [1997]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: /proc file system, seems to -not- have standardisation ?
On Tue, 18 Feb 1997, Theodore Y. Ts'o wrote:
> From: (Alan Cox)
> Date: Mon, 17 Feb 1997 22:33:42 +0000 (GMT)
> I think it is. Certainly if someone came up with a rational format for
> all of /proc, that _didnt_ clash with the existing /proc files I would
> be willing to go for it and to optionally support 'oldproc' files in
> 2.2, and lose them over a couple of years as the tools knew the newer
> formats.
> Whoever does it had better get it right however - we don't want to do
> that more than once

> 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.

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/memory < meminfo, ramdisks, ...
/proc/net < already present as a directory
/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
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

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 < .....

> 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 |
| | 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- ; sysvinit-2.62 ; ; ;
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/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/memory < meminfo, ramdisks, already present as a file
/proc/net < see below. #1 already present as a file
/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

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