lkml.org 
[lkml]   [1997]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: /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



\
 
 \ /
  Last update: 2005-03-22 13:39    [from the cache]
©2003-2011 Jasper Spaans