9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: geoff@collyer.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] General question about hosted interfaces
Date: Wed, 11 Jul 2001 03:32:53 -0700	[thread overview]
Message-ID: <20010711103254.A29FC199DD@mail.cse.psu.edu> (raw)

I'm no fan of USB, but it seems closer to what you want than SCSI.  In
fact, though, SCSI disks (for example) from different vendors do just
seem to plug in and work.  Admittedly adding support for a new class
of SCSI device is more work (unless you just punt the whole problem to
scuzz, and thus largely to the end user).

But the peripherals themselves (or classes of devices) aren't the big
problem, at least for SCSI or USB, it's the interfaces (controllers,
host adapters, whatever) themselves, at least in the wonderful world
of unstandardised PCs.  Plan 9 has drivers for the PCI Buslogic/Mylex
and NCR/Symbios/Tekram SCSI host adapters, but not the PCI Adaptec or
any of the lesser known ones.  And as far as I know, there are at
least two USB interfaces already (logically different and using
incompatible chip sets: UCHI vs OCHI and Intel's chips vs Via's).  Our
biggest headache is VGA cards, which seem to have shelf lives of a few
months, and Ethernet cards, which are beginning to have shorter shelf
lives (can you still get FA310s?) but which fortunately mostly just
reuse a few Ethernet chips (or emulately them inaccurately).

So to have a relatively stable peripheral environment one would need
to (somehow) standardise buses (internal and external), controllers
and their interface protocols, and the protocols between the
controllers and the actual peripherals.  But then the world would
change around us; people want greater speed or utility (Shrug and Pray
on live systems seems to be the only compelling reason for USB over
SCSI).  In the decade or so, the PC has been through ISA, EISA, PCI,
AGP, PCMCIA and Cardbus buses (among others), and PCI is certainly an
improvement over ISA. We've seen IDE/ATA get less stupid (real DMA,
what a concept!), SCSI get faster, USB get invented and then get
faster (to the point of being more than a toy).  Ethernet has gone
from 10Mb/s to 100Mb/s to 1GB/s and I believe the 10GB/s committee is
already at work.  And it's all gotten smaller and cheaper.  Microsoft
try to influence the design of PCs with their periodic standards
(e.g., PC98), but they don't have very good taste in hardware.  I'm
not sure who else has the influence or power to enforce hardware
standards, since nobody is in charge of the overall PC architecture.

I cope by stock-piling cheap supported controllers and trying to
simplify hardware configurations.  For CPU servers and terminals,
booting off floppy lets you avoid local disk entirely if you have
enough RAM, so Ethernet should be the only real pain for CPU servers.
There are several cheap supported cards out now; the NetGear FA310 is
a 2114x, but watch out that the 311 and 312 are not.  For terminals,
there's VGA Hell to be suffered.  The ATI Xpert 98 cards were good for
a while, but now it's hard to find any of them that don't have the
Rage XL engine, and we don't have support for those currently.  It
appears that the Nvidia TNT2 M64 situation is getting sorted out.

All of this is in part why I'd like to get an Ipaq (bitsy) when (if)
they stop being so scarce.  It's got a processor that Intel didn't
design and it looks like the only Intel PC goo in it is a PCMCIA
controller and the flash memory.  No wretched Intel interrupt
controllers, no red-hot glowing CISC processor, no IDE cretinism, 001
USB controller, 001 video interface.  38,000 lines in
/sys/src/9/pc/*.c vs. 11,700 in /sys/src/9/bitsy/*.c.  Amazing what
you can do when there's someone in charge to tell the sleazier
hardware designers, `no, you can't save 5 cents per unit by omitting
DMA, making the software swap the bytes, and leaving out a boot ROM so
that the user has to type in the boot program in hex on the serial
port at every boot'.  I'm skeptical about the bitsy's suitability as a
terminal, but it might make a fine CPU server since it's got what
matters: a reasonable CPU, a lump of RAM and an optional PCMCIA
network card (Wavelan currently).


             reply	other threads:[~2001-07-11 10:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-11 10:32 geoff [this message]
2001-07-12  8:31 ` Douglas A. Gwyn
  -- strict thread matches above, loose matches on Subject: below --
2001-07-12 21:58 jmk
2001-07-12 21:48 bwc
2001-07-13 14:53 ` Douglas A. Gwyn
2001-07-13 15:32   ` Boyd Roberts
2001-07-12 19:51 geoff
2001-07-12 19:45 geoff
2001-07-12 19:31 jmk
2001-07-12 21:09 ` Chris Locke
2001-07-12 21:24   ` Boyd Roberts
2001-07-12 22:01   ` Jim Choate
2001-07-12 18:38 nemo
2001-07-12 15:26 jmk
2001-07-12 18:14 ` Chris Locke
2001-07-13 14:53 ` Douglas A. Gwyn
2001-07-13 15:28   ` Boyd Roberts
2001-07-13 16:46     ` Douglas A. Gwyn
2001-07-14  0:40       ` Boyd Roberts
2001-07-11 10:54 forsyth
2001-07-11 10:58 ` Lucio De Re
2001-07-11 13:26 ` Boyd Roberts
2001-07-11  0:37 presotto
2001-07-10 18:22 rob pike
2001-07-10 19:08 ` Mike Haertel
2001-07-10 23:27   ` William K. Josephson
2001-07-11  8:34 ` Douglas A. Gwyn
2001-07-10 15:17 Douglas A. Gwyn
2001-07-10 18:09 ` Lucio De Re
2001-07-11  8:34   ` Douglas A. Gwyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010711103254.A29FC199DD@mail.cse.psu.edu \
    --to=geoff@collyer.net \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).