Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!ifi!barsoom!tih
From: tih@barsoom.nhh.no (Tom Ivar Helbekkmo)
Newsgroups: comp.unix.i386
Subject: Re: Problem writing device driver for SCO Unix V/386 3.2.0.
Keywords: SCO device driver
Message-ID: <921@barsoom.nhh.no>
Date: 14 Jun 90 20:10:14 GMT
References: <916@barsoom.nhh.no> <20@csource.OZ.AU>
Distribution: comp
Organization: Norwegian School of Economics
Lines: 45

david@csource.OZ.AU (david nugent) writes (on SCO Unix serial drivers):

-> The sample sio driver in the documentation is abysmal; when compiled
-> and linked in - even without modifications and after cleaning up the
-> typo's - doesn't even work.  It's also quite dated under the current
-> kernel version and doesn't support everything required (hardware flow
-> control and additional line disciplines, for example).

Sure -- I know it won't work the way it is, and among other things I
have to figure out what sioputchar() and siogetchar() are supposed to
do.  Still, I've taken on the challenge by now, and am pretty
determined to write a replacement that can handle the multi-port
serial boards that I happen to have...  :-)

I don't worry about hardware flow control and the like.  All I want is
to be able to hook up a two terminals, a serial printer and a slip link
using the age-old "RS237" cable (*grin*) and make them work acceptably
well at low baud rates.  I also hope to learn something in the
process, as I've never written an actual device driver before...

-> You're probably asking the impossible of the hardware.  I'm yet to find
-> a serial card which doesn't advertise that it can share IRQ's (even though
-> you might be able to switch them independantly) and yet can.  What
-> this amounts to is that you probably _CAN'T_ share IRQ's on the card
-> you're using.  It may not have the necessary hardware and logic to do
-> it.

This card *does* advertise that it can share IRQs.  In fact, the
default configuration of the board, as delivered from the factory,
includes shared IRQs.  So it all boils down to, right now, that I need
to know why my kernel becomes unbootable with a "Header read error: 0"
immediately after I press return at the boot prompt when I link my own
sio module into it.  Anyway, I figure I'm doing one of two things
wrong here.  Either I'm calling something that I shouldn't, or I'm
missing a compiler flag that should be there.  I guess I'll try to
reverse engineer the supplied sio module a bit, to see if I can spot
any interesting information that way.

Meanwhile, if anyone who has successfully written a device driver for
SCO Unix could give me any hints or pointers, I'd be grateful!

-tih
-- 
Tom Ivar Helbekkmo, NHH, Bergen, Norway.  Telephone: +47-5-959205
tih@barsoom.nhh.no, thelbekk@norunit.bitnet, edb_tom@debet.nhh.no