-> Specific questions to /proc GURU's, Below.
1) Can symlinks be used in the proc heirarchy without undo
troubles ? I am aware this is very open, And I need that
kind of general answers .
-> Questions to everyone,
1) What is the one(or more) piece(s) of info you are always
fighting to get pulled out of the kernel/driver/filesystem/... ?
> From tytso@MIT.EDU Thu Feb 20 21:04:37 1997
> Date: Wed, 19 Feb 1997 03:12:00 -0500
> From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
> To: "James W. Laferriere" <babydr@nwrain.net>
> Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, alan@lxorguk.ukuu.org.uk,
> linux-kernel@vger.rutgers.edu
> Subject: Re: /proc file system, seems to -not- have standardisation ?
>
> Well, I'll mention what I'm doing with /proc/tty, as an example of what
> I consider to be good proc design:
> /proc/tty contains the following files and directories
>
> driver/
> ldisc/
> drivers
> ldiscs
> driver/ and ldisc/ are directories which contain proc files which are
> registered by the driver or line discpline code itself. For example,
> /proc/tty/driver/serial is where the serial specific information is
> available. (Instead of /proc/serial, as one patch sent to me proposed).
-> Just backgrounder for me,
Are we using the 'tty' above as in /dev/tty ?
If that is the case then I follow the flow you are putting
together here. At first glance I was thinking tty as in
(just) dialin's/terminal-sess.s . (old DEC'y trying to break
bad habits ;-)
> /proc/tty/drivers and /proc/tty/ldiscs are files which contain a listing
> of all of the drivers and line disciplines that are currently
> registered.
-> The below looks cool. I had a thought of maybe a little further
info. describing whats using a particular ttyxxx,
like : ( Is this near same idea you had ? )
> As far as how information in the files should be organized, the current
> format of /proc/tty/driver/serial is as follows:
>
> serinfo:1.0 driver:4.22
> 0: uart:16550A port:0x3f8 irq:4 rx:34 tx:66 oe:4
> 1: uart:unknown port:0x2d8 irq:3
> 2: uart:unknown port:0x3e8 irq:4
> 3: uart:16550A port:0x2e8 irq:3 rx:4412 tx:1142 fe:45 brk:1
> The fields are marked with a colon, fields that are zero are ommitted,
> and there's expansion room for new fields and a new format, if
> necessary.
in /proc/tty/ldisc/ttyS0
base-tty:dos-com1
allocd:pppd ppp0:2.2.0 driver:2.2.0
...
-> Even if that is all there is, it tells someone that the
ttyS0 is allocated by ppp0 & the pppd discipline.
-> This is where getting input on what info others would
like to see here is -very- important.
> As far as your suggestion about moviing around existing items --- think
> very hard before doing so. A few extra pieces of "cruft" in the top
> level of /proc isn't going to be the end of the world..... Is
> /proc/meminfo really that worse compared with /proc/memory/meminfo?
-> This is just what this discussion is about, Should this be
done or not.
/proc/meminfo is just one file with a portion of the info that
is available about the memory system. Do you want to see
only the info presented there available ? (I'm not saying this is
what -you- want, Just asking the question.)
What I would like to see is a set of files displaying the
'state' of the memory system not just,
how much total, used, free, shared, buffers, cached .
Very good info to have but definately not all there is
available to us.
-> Thank you Ted !
JimL
> From neuffer@nomis.i-Connect.Net Thu Feb 20 21:04:54 1997
> Date: Wed, 19 Feb 1997 00:19:03 -0800 (PST)
> From: Michael Neuffer <neuffer@nomis.i-Connect.Net>
> To: "James W. Laferriere" <babydr@nwrain.net>
> Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, alan@lxorguk.ukuu.org.uk,
> linux-kernel@vger.rutgers.edu
> Subject: Re: /proc file system, seems to -not- have standardisation ?
> On Wed, 19 Feb 1997, James W. Laferriere wrote:
> > 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 ;-)
-> ...snip...
> > /proc/storage
>
> The sheme breaks right here. It implies that either you distribute all
> SCSI devices all over the place (and you would still have the SCSI
> controllers themselves, which you would have to put somewhere) or
> that all SCSI devices are storage devices, which they definitely are not.
-> NOT, I mean this emphatically.
strorage is for 'storage devices' not -all- scsi or all eide or
all ...., Just storage devices .
-> And that is only if the idea of using the heirarhy 'storage'
seems like a good place to put it. This discussion is just to
nail down what -we- as a best effort, should put into, where this
info should be, that is made available to the user.
> > > 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.
> No, but what you can see it that you have active drivers of certain types,
> to which are tied certain controllers.
-> With what I presented in the previous message this could be
determined also, with just as much ease.
> This is a driver centric view, which gives you more information
> on first sight then what you suggest. It also immediately what format
> to expect if you look at the driver/controller infromation.
-> Which is just fine, But not all people see things in a driver
centric view. Most people I know see things (sometimes) better
as a connections based view. Such as:
At-Bus-> Scsi-Ctlr-> Disk-0-> Disk-1-> Tape-0-> Terminator.
-> Yes , No ?
> With you solution this would not be possible, or you would have to try to
> standarize the information you can get from them, but that is like trying
> to get a professional dancer, a professional football player and a baker
> to wear the same clothes. It does not fit, they are too different.
-> The IDEA behind 'STANDARDS' is the dancer dances but to the
tune of the standard, the football player scores, but to the
direction by the standard.
-> Without standards there is nothing from which to build the next.
-> Thank you, Michael
JimL
> From tenthumbs@cybernex.net Thu Feb 20 21:06:29 1997
> Date: Wed, 19 Feb 1997 18:41:24 GMT
> From: tenthumbs@cybernex.net
> To: linux-kernel@vger.rutgers.edu
> Subject: Re: /proc file system, seems to -not- have standardisation ?
> On Mon, 17 Feb 1997 22:33:42 +0000 (GMT), you wrote:
> > 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
> >
> > Alan
> If I were doing it (and who would want me to ;-)),
>I would go for something like
> /proc/drivers
> /proc/drivers/block
> /proc/drivers/char
> /proc/fs
> /proc/net
> /proc/arch
> etc. Basically, follow the source code tree.
-> Something I was very much interested in doing, Although when I
did a tree of the sources (IE:2.0.29) I was -very- disheartened.
I really was hoping to see a little more directivity for me to
follow, It wasn't there to my point of view. :-{
-> Of these only 1, 3, 7, 9 & 10(*), 11, Seem to have any pertinance
to the proc tree. (*) driver & modules may actually be able to
be tied together, at least I beleive so.
> 1 ./fs
2 ./init
> 3 ./kernel
4 ./lib
5 ./mm
6 ./include
> 7 ./net
8 ./ipc
> 9* ./drivers
> 10* ./modules
> 11 ./arch
12 ./scripts
13 ./Documentation
-> any other good possibilities & suggestions here ?
> Since the whole filesystem is fake anyway, it should be possible to simulate
> symlinks for the current files which would keep old code happy.
>Eventually, the
> symlinks would disappear. For example, /proc/ioports becomes a symlink to
> /proc/arch/ioports.
> Just an idea.
-> Just what Alan had envisioned, I beleive .
But, I have asked the question of whether they would be problems.
Thank you, tenthumbs
JimL
> From abszero@epix.net Thu Feb 20 21:07:18 1997
> Date: Wed, 19 Feb 1997 16:02:31 -0500 (EST)
> From: root <abszero@epix.net>
> To: "James W. Laferriere" <babydr@nwrain.net>
> Subject: Re: /proc file system, seems to -not- have standardisation ?
>
> James W. Laferriere wrote:
> > On Tue, 18 Feb 1997, Theodore Y. Ts'o wrote:
> > > From: alan@lxorguk.ukuu.org.uk (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.
> >
> > 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,...
>
> Suggestion: /proc/bus is a link to /proc/<yourbus>.
> /proc/<yourbus>/<whatever>s/<whatever#> is a link to the file (or dir)
> containing info on that device. Eg for ISA you might have /proc/isa/slots/1
> which is a link to /proc/audio. (if slot 1 contained a soundcard)
-> Good Idea..., Its usability(Ie: should it be done) is another ?
I'll am asking this question at the beginning of this message.
> > /proc/tty < terminal-sess.s,... you've already done.
> > /proc/cpu < cpu's.. ? already present as file cpuinfo
>
> for SMP syses, there should prob. be a /proc/cpu/<#> directory, so for
> single-processor syses, all would be under /proc/cpu/1 (or 0, depending on
> std SMP lingo), or /proc/cpu/1 would be a link to /proc/cpu.
-> I am not very enamored of numeric directories or files
Slo'vinly'aris is one place this is used that comes to mind.
Something like cpu0,cpu1, even if they are in a directory
named cpu is still more descriptive than 0 1. Albiet redundent .
> > /proc/graphics (video ?)
> A 3d subdir would be a Good Thing, as I bet (for a while anyway) there will
> be a lot of kruft that will accumulate here, and it would be best to
> keep major directories from getting krufted to death.
-> Are you willing to draft a structure ?, And if not, all suggestions
will be looked at & I'll try to get it into a readable form soon
there after.
> > /proc/io
> shouldn't serial and parallel be in here?
-> Nasty thing with this name is that (almost) everything is IO
on a computer ?-), But if the directory 'io' is the way to
go, then probably so . Reason why I'm saying this is Ted Ts'o
is working on a structure very close to this. (See above)
-> ...snip...
> > /proc/pointing
> How much proc stuff is there for pointing devices? Note that the INTERFACE
> TO (PDP, busmouse is under io, serial is under serial) the mouse wouldn't go
> under here anyway.
-> mice, tablets, joysticks, touchscreens, ...... make a guess.
-> ...snip...
> > /proc/storage
> Good Idea! The info on your hard drive is WAY to hard to get now.
-> Thank you. Also please see above to a comment from
Michael Neuffer who thought otherwise, he has brought out
some good points concerning this area .
> > /proc/dev < already present as file devinfo
> Full of links, no doubt
-> oops I goofed, ^^^^^^^
It is file '/proc/devices' & gives us -some- useful info.
I would really like to see it expanded to provide more.
-> Thank You James
JimL
> From karl@ronin.u-net.com Thu Feb 20 21:07:42 1997
> Date: Wed, 19 Feb 1997 20:25:55 +0000 (GMT)
> From: "Karl R. Heyes" <karl@ronin.u-net.com>
> To: "James W. Laferriere" <babydr@nwrain.net>
> Cc: linux-kernel@vger.rutgers.edu
> 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.
-> ...snip...
> > /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??.
-> Yes please do, I am also very interested in getting this
done 'The Right Way' (tm;-), as Alan & Ted have said this is a
do once and we had better be right the first time, kind of
project.
>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.
-> Alan has decree'd that he would allow these changes IF they
did not effect the present /proc heirarchy. Being that as a
given, then we will continue.
Are you suggesting something like ? :
/proc/proc/..
/proc/dev/..
/proc/system/..
> So a possible structure could be :-)
>
> /dev/null
> /dev/hda /dev/ide0/[ab][1-16]???
> /dev/hda1
> /dev/scsi0/disk0
> /proc/1/...
-> ^ What is this pertaining to ?, Process #1 I'll bet. OK.
> /system/modules/ide/.... <module specific stuff>
> /system/modules/sound/...
->/system/devices/sound/... < non-modules ????????
^^^^^^^ <----------< Is being used as our descriptor .
I do still beleive that the Modules & Devices systems can be
combined into one directory, as Both are 'Drivers' just of
differant methodologies. One is hard coded into the running
kernel the other may or may not be loaded at any one time.
> /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.
-> Yup, And thank you for the input... ;-)
> If you are interested, I'll get back to it, and back to looking at
> kernel code.
-> Thank You karl, And please do get involved
the more the merry'r. ;-)
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. ;-) ---