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