Path: utzoo!mnetor!uunet!nuchat!steve
From: steve@nuchat.UUCP (Steve Nuchia)
Newsgroups: comp.unix.microport
Subject: Re: telebit on uBug 286 - update
Message-ID: <911@nuchat.UUCP>
Date: 9 Apr 88 06:24:16 GMT
References: <656@omen.UUCP>
Organization: Public Access - Houston, Tx
Lines: 77

From article <656@omen.UUCP>, by caf@omen.UUCP (Chuck Forsberg WA7KGX):
> In article <878@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes:
> :I will take this opportunity to renew my call for interrupt-driven
> :driver sources for microbug.  Anything at all would be handy.

> With a few arcane exceptions, all Unix sio drivers are interrupt driven.
> The problem with hish speed serial input is that other parts of the

Perhaps I should have been more clear (or at least less terse).  What
I am looking for is specifically a _microport_ driver of non-trivial
construction.  I have the ramdisk, speaker, and pty drivers.  The
pty driver is some help, since it excersizes the clist access routines
and the ioctl interfacing.  But none of these drivers do any interrupt
munging, and this is where things get wierdest (ie, least commonality
among different unix ports).  The chances of using something like
a 3B2 driver as a go-by and getting a production quality driver
for uBug are pretty slim.  (working, maybe.  good, probably not).

I am installing a machine for a client next week.  It could run
microbug.  I would prefer that it did, since I am very familiar
with microbug.  "The devil you know" and all that.  But, since
they won't support high-capacity disks and don't work properly
with the low capacity disks its out of the question.

I signed a contract with them months ago that was supposed to
get me source for the disk driver so I could make it stop
eating my disks (I'm suffering the two drive problem).  As
an additional excersize I was going to make it handle the
large drives too.  Nothing happened.  To be fair I did start
to work on fsck for them a while back, but that code is so
nasty that I stopped when I found a work-around that worked
for me.  Since then two (different) "engineers" have called
me asking what I knew about it.  I can only assume the first
one is in an assylum, and wish his replacement better fortune.
Fsck.c is a swamp: abbandon all hope, ye who would enter there.

Drivers, on the other hand, are at least shorter and more
steryotyped than fsck.  If they are worried about me not
finishing work on it they could always offer me, say, 5%
of the upgrade charges they will reap when they ship the
fixed drivers.  Of course if they never get them fixed
they can still rape us for a few more placebo updates before
we show up on their lawn with pitchforks and torches.

This stopped being funny over a year ago.  I'm real tired
of having files eaten by their broken driver.  Their defective
serial driver is costing me money - to the tune of about
a hundred dollars a month in communications cost (It won't
let me run my telebit fast).  I have offered to fix these
things for free.  They have ignored me.  If this keeps up
much longer I'll start disassembling.

I've thought about litigation, but as I understand the law
they have only to offer me my money back.  Since I never
used it for anything important (since it never worked)
I don't have any concrete damages, although if I billed them
for all the hours I've spent nursing their broken fsck through
fixing the filesystems their broken driver trashed it would
be a healthy sum.  So the probable outcome of a suit is that
I'd walk away with half as much money as I'd need to buy
the replacement system I'd need because I had to give them
theirs back to get the settlement.  I don't want a wash,
I want what I paid for - "real unix" (remember the adds?).

real unix doesn't eat disks.

So, in the absence of any sign of intelligent life from
microport, I am hoping to collaborate with someone on
writing replacement drivers from scratch.  Anyone with
anything concrete to bring to the discussion please
respond by mail.  If we can avoid contaminating the
project with any AT+T-stained code we'll all be better off,
even if it takes a little longer.
-- 
Steve Nuchia	    | [...] but the machine would probably be allowed no mercy.
uunet!nuchat!steve  | In other words then, if a machine is expected to be
(713) 334 6720	    | infallible, it cannot be intelligent.  - Alan Turing, 1947