h a l f b a k e r yI think, therefore I am thinking.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
A major reason why SCSI adaptors are more expensive than
IDE adaptors, is that they incorporate some onboard
processing power, so as to reduce the load on the Central
Processing Unit. However, have you noticed the plethora of
DRIVERS that have to be loaded for SCSI devices? When
the CPU has to
run these drivers to communicate with the
SCSI devices, the original purpose of SCSI is being defeated! So what we need are SCSI adaptors that have
programmable memory onboard. If you had such an adaptor, then no matter what SCSI device you wanted to hook up to it, the drivers that come with that device would be
loaded into the adaptor memory, semi-permanently. The main system CPU would only be involved once, during the initial transfer of driver from external file to adaptor memory. Then the adaptor would run the driver, not the CPU. All the CPU would have to do is tell the adaptor that it wants some
sort of data from a particular device, and the adaptor would do ALL the work of fetching it.
Now, when is something like this going to be available?
SCSI-3 spec
http://www.cubic.or...csi_iii/spc_r06.txt
Writeup of the SCSI-3 spec [johan, Jul 01 2000, last modified Oct 21 2004]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., https://www.coffee.com/
Description (displayed with the short name and URL.)
|
| |
This is so confused. Where to start? |
|
| |
Device drivers exist to provide an interface between the host operating system and some piece of hardware. They are only necessary if the operating system doesn't already know how to talk to the hardware. If there's a standard interface for talking to hardware, then no drivers are needed. |
|
| |
For example, you will never have to load a driver to talk to a SCSI hard disk. That's because the SCSI standard explicitly defines the command set used to talk to disk drives (determining their geometry, formatting them, reading and writing, etc). *This* (having a standard interface) was the initial purpose of SCSI, not some business about offloading CPU! |
|
| |
(Yes, some IDE controllers require more host CPU time than some SCSI controllers, but that has more to do with design tradeoffs with Intel PC architectures than anything else.) |
|
| |
When people started using SCSI for other purposes (removable media, scanners, printers, cameras, ...), there was no well-defined command set for these non-hard-disk devices. As a result, each device speaks its own "language", and requires drivers to talk to each different operating system. |
|
| |
The SCSI adapter doesn't care about these drivers. As far as it's concerned all the traffic is just a set of SCSI messages going back and forth between the CPU and the SCSI devices. It neither knows nor cares what these messages "mean". |
|
| |
That means that the notion of having "the adaptor run the driver" is not just half-baked -- it's downright raw. The driver's purpose is to tell the host OS what to do with the device, *not* to perform some computational function that could be taken offboard. Drivers add complexity to the setup process, but they do *not* add any more computational load to the host CPU. |
|
| |
Now, you still have a problem (proliferation of drivers for non-hard-disk SCSI devices). There are two ways to solve this problem: |
|
| |
1. Define standard command sets for talking to each class of devices (scanners, printers, ...). Encourage hardware manufacturers to follow these standards. This will allow operating systems to talk to these devices without any drivers. |
|
| |
2. Put driver software in the device. This software gets loaded, *not* into the adapter, but directly into the host CPU. Of course, these drivers will have to be tailored for a specific operating system. (Either that, or we come up with a standard driver interface layer.) |
|
| |
Sorry, but I have seen some statistics regarding
percentage of CPU time required while SCSI devices
under various circumstances are accessed, and that
percentage can vary from 5% to 25%. A perfected SCSI
technology would be designed to accommodate any
SCSI device, and the CPU utilization would ALWAYS
be minimal. I have a '486 system that I use for old DOS
games that cannot be played on today's superfast
computers, and this is a most unusual SCSI system.
It has a SCSI CD drive and a SCSI MO drive, and NO
hard drive. The MagnetoOptical drive is C:, and I boot
from A:, loading drivers. Once the boot process gets to
C:, I can continue booting to any of several versions of
DOS, or Windows 3.1, or OS/2, or Linux...depending only
on what MO cartridge is in the drive.
Now I would prefer to boot directly from C: all the time
(can only do it with 540MB MO cartridges that have 512
bytes per sector, and not the 640MB cartridges that have
2048 bytes per sector. So far as I've checked, nobody
yet makes a SCSI controller that can handle 2048-byte
sectors, without loading drivers. The raw idea presented
originally was groping towards a final generic solution to
all future hardware that might be hooked to a SCSI
controller. |
|
| |
I think this suffers from "the last 10% of the solution takes 100% more time" rule of design. 90% of SCSI devices are fixed disks that don't require any additional driver commands. The remaining 10% (weird disks, CD-ROM, CD-R, CD-RW, scanner, ZIP, JAZZ, MO etc., SCSI-connected network interfaces) devices are so different that it would take just as long (if not longer) to design a controller to speak with *any* possible device. |
|
| |
Ignoring practicallity, i've thought it'd be cool to have a multi-ported device that would be able to identify what protocol and interface standards it was connected to automatically. So you could plug just about *anything* (of some reasonable voltage) into it one of its myriad ports (db-15 db-25, db-9, rj-45, rj-11, USB, etc.) and it would figure out what the protocol was and interact with the device. Plug another thing into another port, and it would figure out how (if possible) to translate between the two devices. Sort of a break-out box with a brain.| — | johan,
Jul 02 2000, last modified Jul 04 2000 |
|
|
| |
I think I have to disagree about it being so tough for a
controller to correctly "speak" to any possible SCSI
device. See, when the CPU has its drivers loaded, IT
knows how to make the SCSI controller talk to the various
SCSI devices. All I want to do is put a minimal CPU on a SCSI controller, along with appropriate semi-permanent memory. The drivers for any particular SCSI device would be written for that CPU, and not the main CPU of the overall computer system. All THAT CPU needs to know is how to tell the SCSI CPU to "go fetch" (or "go put"). The details of the fetching are supposed to be in the SCSI CPU drivers.| — | Vernon,
Jul 03 2000, last modified Jul 04 2000 |
|
|
| |
I'm not intimately familiar with the SCSI protocol, but i think device-specific drivers often exist to handle non-standard issues regarding a particular device. A lot of different SCSi devices exist, some of which have fairly exotic capabilities, when compared with a run-of-the-mill SCSI hard disk. For example, unlike a fixed disk, a scanner might have multiple (scanning) modes that do high or low resolution scans. The CPU needs to be able to signal the scanner to switch modes. I think it's these sorts of differences that require drivers. |
|
| |
Don't get me wrong; i agree with you. It should be possible to move just about all of the commands into the controller chip. But if a designer comes up with a new device that has some attribute not explicitly supported by a command in the latest SCSI spec, they can either wait for a new SPEC, or provide a driver that can provide a better interface to the device-specific attributes they have built into their device's SCSI protocol. And there just aren't that many revisions of the SCSI spec. |
|
| |
Even if there still had to be drivers for the main CPU to communicate some totally new notion to the hypothetical SCSI-controller CPU, those drivers need not be very long and involved. Part of my objection to the current driver situation is the tens of thousands of bytes each one gobbles from the RAM needed for DOS games, heh heh.
THOSE are the drivers that properly belong on the SCSI card, moved there by the System CPU, and moved into the previously-mentioned programmable memory. Any other System-CPU driver could and should be very very small. For example, a SCSI scanner may have several
different scanning modes, but all of them fit into the "go fetch" category. If the System CPU needs to be a bit more specific, such as "go fetch from SCSI device #4, with control sequence "blah blah (not necessarily unlike an old Hayes modem-control string) blah blah", then that
is not a lot of stuff the the CPU to know. In fact, the main scanner software program would be passing such a control-string through the System-CPU to the SCSI CPU, and again no special SCSI-scanner System-CPU driver is necessary. |
|
| |
I need to mention something that got left out. On the suggested SCSI controller card would be the appropriate circuitry for communicating with SCSI devices, a modest CPU, and an appropriate amount of programmable/reprogrammable memory. If an average SCSI driver takes 40,000 bytes, and the SCSI controller can handle 15 devices, then there should be 600K of programmable memory, minimum. During the installation of a particular special SCSI device (unlike standard SCSI hard drives), the System CPU would tell the SCSI CPU to receive and store a driver about to be transmitted. If the device is uninstalled, the memory occupied by the driver should be erased, thereby being available for the driver of some other SCSI device. Perhaps I am belaboring the obvious, but sometimes leaving out the simplest thing leads to ridiculous problems.... |
|
| |
I need to mention something that got left out. On the suggested SCSI controller card would be the appropriate circuitry for communicating with SCSI devices, a modest CPU, and an appropriate amount of programmable/reprogrammable memory. If an average SCSI driver takes 40,000 bytes, and the SCSI controller can handle 15 devices, then there should be 600K of programmable memory, minimum. During the installation of a particular special SCSI device (unlike standard SCSI hard drives), the System CPU would tell the SCSI CPU to receive and store a driver about to be transmitted. If the device is uninstalled, the memory occupied by the driver should be erased, thereby being available for the driver of some other SCSI device. Perhaps I am belaboring the obvious, but sometimes leaving out the simplest thing leads to ridiculous problems.... |
|
| |