Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!ncar!husc6!bloom-beacon!spdcc!dyer
From: dyer@spdcc.COM (Steve Dyer)
Newsgroups: comp.unix.microport
Subject: Re: 2 ESDI drives, and misc. flames
Message-ID: <1546@spdcc.COM>
Date: 29 Jul 88 14:52:30 GMT
References: <138500039@cdp>
Reply-To: dyer@spdcc.COM (Steve Dyer)
Organization: S.P. Dyer Computer Consulting, Cambridge MA
Lines: 29

In article <138500039@cdp> steve@cdp.UUCP writes:
>Another interesting note.  In a fit of frustration, I tried to
>link the 386/ix hd.o driver into the uPort kernel.  The link
>failed, with undefined (global) symbols 'dpt1' and 'dpt2'.  I
>find it outrageous that Microport decided to break the SVR3
>driver interface.  After all, isn't the success of UNIX based
>on the standard interfaces it provides ?
>
>As another experiment, I tried to link Microport's Everex tape
>driver (ev.o), into a 386/ix kernel.  But this also failed --
>and you can guess who's software introduced undefined symbols !
>ev.o references 'dmainitted' and 'initdma'.  Incredible.
>

Ha hah haahahahahahhaha....

"Standard interfaces" are at the system call and library level,
not at the device driver binary level.  That, for better or worse, is
far far far from being standardized.  It's a nice direction to aim for
the future, now that we are moving towards standard kernels (it *would*
be nice to buy a tape/disk/worm/serial driver from a 3rd party and not
have to worry about this, but that's just not how business is done yet.)
You may dislike Microport, but this is standard practice: device drivers
are tightly integrated with a particular revision of a kernel; it's no
reason to single them out for bitching.

-- 
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer