From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.unix.pc-clone.32bit
Subject: Re: No EISA support SVR4.2
Date: 25 Jan 93 17:57:23 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <2B6221EB.123E@telly.on.ca>, evan@telly.on.ca (Evan Leibovitch) writes:

| >it seems EISA SCSI will have to wait
| >until USL releases 4.2.2
| 
| Sez who?
| 
| According to every Univel compatability list I've seen (including ones
| produced before its release), support for EISA host adapters is
| explicitly provided for UNIX V4.2 --- *by the vendor of the host board*.


| A growing trend -- that I welcome -- is to put the support for
| third-party hardware drivers in the hands of the hardware maker, not the
| Unix vendor. This allows the driver to be as up-to-date as the hardware,
| and put control of its development in the hands of the people most
| intimately familiar with the hardware. It also relieves the Unix vendor
| from having to track all the boardmakers out there, leaving them to
| concentrate on the Unix propser rather than external drivers.

  In actual experience, this generally doesn't work well. WHile there
are exceptions, hardware vendors are generally better at making hardware
than writing drivers for UNIX. And responsible vendors will include
drivers, because new versions of the o/s would never get installed
otherwise, or all vendors would have to agree on a way to install
drivers at boot time. Not impossible, but it just isn't here right now.

  Companies, such as SCO, provide drivers for popular hardware. They
then support it, so that you can upgrade your software. A case in point
is SCO, with drivers for boards no longer manufactured, but still
support by SCO. To a company with a large installed base this is "value
added" for sure.
| 
| This has worked for years with the makers of intelligent serial boards.
| You don't buy anyone's UNIX expecting it to have built-in drivers for
| Digiboards or Equinox. IMO, in the interest of keeping bloat to a
| minimum, basic UNIX should come with a minimum of hardware drivers
| and let the rest ship with the peripherals.

  There are many devices not needed for system boot or install, but hard
disk isn't usually considered optional. I'm pretty happy with letting
the market decide on this one, but as a buyer of systems I'd like to
minimize hassles on upgrade, and I'm most likely to upgrade the systems
which include drivers with the o/s.

  In a "customer comes first" approach the hardware vendor would supply
the original driver, perhaps by paying the o/s vendor to write it, and
then the o/s vendor would supply updates as the o/s changed, and the
hardware vendor would supply info on any bugs and/or revised versions of
the board.

  In the real world we have a mix of support or lack thereof. I still
wind up hacking FAS for a lot of systems. While vendors like Adaptek can
write a working driver, you get drivers like the Ultrastor EISA ESDI
which is really fast but doesn't provide info for sar and other tuning
tools, and even {name_deleted} who's driver is the sorriest, most
unreliable, slowest and generally abysmally disgusting piece of garbage
I've ever seen. And their response to complaints was "so, use DOS."
| 
| Part of the problem (to the person buying R4) is that most hardware
| companies who have done drivers for UNIX have done SCO versions and
| stopped there. This appears to be changing, as Univel has aggressively
| been going after IHV support (and its 62-page compatability guide
| reflects this). Consensys and other 4.2 releases should generally be able
| to piggyback on this increased availability of 4.2 hardware drivers.

  No disagreement on this point at all, SCO no longer holds the only
large market share, and since V.4 drivers (usually) work on all vendors,
that sort of counts as a single market segment.

| Given a choice, I'll take the Adaptec-supplied 1742 driver over the USL
| one, thank you.

  Adaptek write drivers which are at least functional. I personally find
the difference between good drivers for Adaptek cards to be minimal;
most people have gotten just about all there is. If the drivers in an
o/s were up to SCO or Dell standards I would not bother to change them.
If the stock USL drivers prove slower or unreliable I'd change, but not
for a few percent, because the added hassle of maintaining the system
doesn't justify it. That's not an absolute, some people may find other
solutions.

| >It ALWAYS happens that people want the latest and greatest and then get
| >burned by the bugs and deficiencies.
| 
| Naah. We let people like Larry Snyder jump on the various bandwagons,
| and just wait until he stops falling off.

  Small sites should probably stay away from the bleeding edge, but
larger sites should use new stuff and document problems and suggestions
to the vendor, because fixes are cheaper in the development cycle.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	A terible poker player can have a great hand,
	A obnoxious fool can have a good idea.
	Both are winners, regardless of who has them.
Xref: sparky comp.unix.pc-clone.32bit:1380 comp.unix.sys5.r3:450 comp.unix.sysv386:17934