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

Michael Neuffer (neuffer@nomis.i-Connect.Net)
Sat, 22 Feb 1997 18:23:48 -0800 (PST)

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:

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

> > 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. 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.

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.

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.

Mike

Michael Neuffer i-Connect.Net, a Division of iConnect Corp.
mike@i-Connect.Net 14355 SW Allen Blvd., Suite 140
503.641.8774 Beaverton, OR 97005