Re: Re: /proc file system, seems to -not- have standardisation ?

James W. Laferriere (babydr@nwrain.net)
Sat, 22 Feb 1997 20:57:21 -0800 (PST)


On Sat, 22 Feb 1997, Michael Neuffer wrote:
> On Sat, 22 Feb 1997, James W. Laferriere wrote:
> > > 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.
>
> See, further down.....
>
> > > 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 ?
>
> That is similar to how *BSD does it. This is fine and dandy, but in this
> case you must give up your storage idea. Only a subset of SCSI devices are
> storage devices. It would more look like:

I do not beleive that needs to be the case here at all.
the storage heirarchy is just that a storage information
central so what if it contains duplicated data. Does this
hurt anything that you know of ?

> PCI-Bus-> Scsi-Ctlr-> Disk-0-> Processor-0-> Disk-1-> Scanner-0 ->
> Tape-0-> Terminator

Michael, What type of processor are you speaking of here ?
I would assume a generic processor of -any- type that may
be processing scsi-data in the chain . IE: another scsi node.
Let's get its information and get that to the user. ;-)

> > > 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.
>
> You didn't get it. The "lowlevel" SCSI controller themselves are like
> like dancers, footbalplayers, bakers, street sweepers and a thousand other
> incompatible jobs.
>
> In reality the only thing they have in common is that they somehow,
> somewhere are able to contact SCSI devices and somehow to
> talk to the host they live in.

OK, Now we get to tthe crux of the matter .
Whats wrong with giving it a patina of readability ?

>Some controllers like a ST-01 need to be
> told when to wiggle which wire on the SCSI bus. On the other extreme end
> of the spectrum you have controllers like the DPT SmartRAIDs that are
> really more like autonomous IO subsystems, that just happen to talk to you
> via a defined protocol and do lots of processing and error handling
> inside.

Most of this could be provided in a file st01-specific
in the directory scsi'n' and the dpt-specific .

> The information you can get from those controllers is so different
> that it is next to impossible to standarize the presented information
> (or supported IOCTLs). You will have a tiny common subset and huge numbers
> of specialized extensions.

Even you say -next to- but not impossible.
OK, then lets give them that tiny common subset & then
in the specific files what we have left ?

> When I wrote the /proc/scsi code I already thought about this, since my
> original idea was to standarize the in/output of the driver/controller
> information so that tools could easily manipulate this.

Then you are the only person who I -must- convince that
there is some good in what I am trying to get defined .
Please help me get the idea you have & mine combined into
an extremely user friendly & hopefully programmer friendly
/proc filesystem.

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 |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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. ;-) ---