The only reason I put forth the same style of driver-centric
view of proc, is I beleive that the present maintainer of
/proc/scsi won't go for /proc/scsi/scsi0/.., /proc/scsi/scsi1/..
approach . ( Believe me, I've asked. At least not without alot of
further work/enhancements to the scsi layers )
But the driver-centric approach is alright as long as it is
used for all areas that use/need a driver.
I prefer the eth0, eth1, scsi0, scsi1, approach . :-)
Tnx, 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 |
+-----------------------------------------------------------------------+
|-> Linux-Vax Port, Still in Progress . IE: No Progress To Report ;-) <-|
+-----------------------------------------------------------------------+
> On Tue, 15 Apr 1997, Mr. James W. Laferriere Network Engineer wrote:
>
> > On Tue, 15 Apr 1997, Miguel de Icaza wrote:
> > > > > And then, if people want to parse any of the extra information, they
> > > > > should know the architecture specific information on the CPU before
> > > > > attempting to parse it.
> > > >
> > > > It should be standardized. Right now there's *no* standardization in the
> > > > kernel, which makes parsing the information the biggest pain in the ass.
> > > > Having to write 5 different parsers for the same information is *not* the
> > > > way to go.
> > >
> > > Well, first problem is: which applications would really care about the
> > > information on /proc/cpuinfo? i doubt there are any applications that
> > > require this information besides probably the cpu type.
> > >
> > > We could have a standard part /proc/cpuinfo part for those
> > > applications that care about this and a architecture-specific part.
> > >
> > > The standard part should have:
> > >
> > > global: the port name, architecture type, number of cpus on the
> > > system, number of active cpus on the system.
> > >
> > > per cpu: the cpu type, the fpu type, mmu type, bogomips.
> > >
> > > The rest should be architecture dependant.
> >
> > Hello Miguel & et-al,
> >
> > how about the /proc/net directory ?
> > I haven't seen mentioned the lack of device-driver informantion
> > in this directory .
> >
> > The reason I am very interested in the below is that I -will-
> > be creating systems with as many as 8 ether cards in them OR
> > 4 ether cards & 3 T1/E1 cards, Are we getting the idea yet ?
> >
> > Also If I should maybe sell one of these to a friend to use
> > in a small routing situation they may want to put in one of
> > their own cards.....
> >
> > Could we try an idea like : (to re-quote partially my previous
> > email)
> >
> > ------------------------------------------------------------------------
> > What I hope could be usable,
> >
> > for:
> > /proc/scsi/ncr53c8xx-0 < dir to info about ctrl 0 driver.
> > /proc/scsi/ncr53c8xx-0/ctrl
> > < info about ctrl 0 driver.
> > /proc/scsi/ncr53c8xx-0/devices
> > < info about devices on ctrl 0 .
> > /proc/scsi/ncr53c8xx-0/?????
> > < further info about devices &/or ctrl 0 .
> >
> > (If scsi0 (from dmesg) is ncr53c8xx-0 then a link or pointer back
> > to scsi0 may be in order.)
> >
> > /proc/net/eepro100-0 < dir to info about ctrl 0 driver.
> > /proc/net/eepro100-0/ctrl
> > < info about ctrl 0 driver.
> > /proc/net/eepro100-0/????
> > < info about ????
> >
> > (If eth0 (from dmesg) is eepro100-0 then a link or pointer back
> > to eth0 may be in order.)
> >
> > IE: xxxx-xxxxx-0 is the first instance of the driver xxxx-xxxxx
> > in the system.
> >
> > ------------------------------------------------------------------------
> >
> >
> > 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 |
> > +-----------------------------------------------------------------------+
> > |-> Linux-Vax Port, Still in Progress . IE: No Progress To Report ;-) <-|
> > +-----------------------------------------------------------------------+
> >
> >
>
>