Messages in this thread | | | Date | Wed, 19 Feb 1997 20:25:55 +0000 (GMT) | From | "Karl R. Heyes" <> | Subject | Re: /proc file system, seems to -not- have standardisation ? |
| |
On Mon, 17 Feb 1997, James W. Laferriere wrote:
> > Please bear with me for approx. 1 min. of your time. > > I have been noticing a very dis-heartening lack of flow > to the use of the /proc files. Most driver developers seem > to just make up names as they go & then others don't seem > to use this feature fully. I would like to put forward a > suggestion for structure (Someone else has to have already > been here! ;-) IE: > > /proc > /proc/dev > /proc/dev/audio > /proc/dev/b.... > /proc/dev/.... > /proc/dev/net < these are my areas of greatest > /proc/dev/net/eth0 < concern on the subject. > /proc/dev/net/eth1 <-- This line would allow the > /proc/dev/net/eth... < testing for eth1 & then > /proc/dev/scsi < ifconfig'ng it. > /proc/dev/scsi/scsi0 <-- These lines tell me I have > /proc/dev/scsi/scsi0/disk0 < controller 0 & 2 disks, > /proc/dev/scsi/scsi0/disk1 < ... > /proc/dev/scsi/scsi0/tape0 < & a tape drive > /proc/dev/scsi/scsi0/cdrom0 < & a cdrom. > /proc/dev/scsi/scsi0/.......... < & ????....... > /proc/dev/scsi/scsi1 < Controller 1 & >
It's interesting to see something like this appear again. I certainly agree (along with most people) that a standard should be defined.
I've also looked at this from originally the devfs angle. Maybe I should pick it up again??. The idea was to have three directory tree's /dev, /proc, /system. /dev contains the files for accesing the devices in a Unix-like way. /proc for detailing only process information, and /system for presenting control/information files.
So a possible structure could be :-
/dev/null /dev/hda /dev/ide0/[ab][1-16]??? /dev/hda1 /dev/scsi0/disk0 /proc/1/... /system/modules/ide/.... <module specific stuff> /system/modules/sound/... /system/kernel/... /system/meminfo /system/cpuinfo
This is of course only a small bit. There's a alot of other things to account for, like a name cache for perm's and onership of non-loaded modules under the control of kerneld. However, it should give you an idea of what it should look like.
If you are interested, I'll get back to it, and back to looking at kernel code.
cya
karl
| |