Path: utzoo!attcan!uunet!ogicse!uwm.edu!cs.utexas.edu!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!eagle!news
From: fsset@neptune.lerc.nasa.gov (Scott E. Townsend)
Newsgroups: comp.sys.amiga.tech
Subject: Re: A guide for prospective device driver writers (LONG)
Keywords: device driver
Message-ID: <1990Jun1.162516.22925@eagle.lerc.nasa.gov>
Date: 1 Jun 90 16:25:16 GMT
References: <3159@bnr-rsc.UUCP>
Reply-To: fsset@neptune.UUCP (Scott E. Townsend)
Organization: NASA/Lewis Research Center, Cleveland
Lines: 59

In article <3159@bnr-rsc.UUCP> mwandel@bnr-rsc.UUCP (Markus Wandel) writes:
>Below is a file which I wrote recently about Amiga device drivers.  I think
>it might be useful to some people, and lacking other convenient distribution
>mechansims, I'll just post it here.  This doesn't have to be the final version
>of the document; feedback would be appreciated and if someone wants to write
>an additional section covering material I don't, I'd appreciate that too.
>
>Is there *any* real documentation from Commodore on this subject?
>
>Markus Wandel
>uunet!bnrgate!bnr-rsc!mwandel
>

Just a note that might be common knowledge to the net, but wasn't to me.

It appears that ramdev.asm in the 1.3 RKM Includes and Autodocs manual has
a bug.  The scenario is to build with the EXERCISE_TASK flag turned off.
This causes as much activity to occur in the calling task's context as
possible.  What I found was that for slow devices, it is possible for
the unit task to get hung in such a way that all further device activity
is frozen.  (I don't have any DevCon notes, so maybe this is fixed in
the notes referred to in the above article)

What seems to be happening is that the flag the task uses to determine if
the device is 'active' was causing a classic 'deadly-embrace'.  (Sorry, I
don't have my code here, so I don't remember the name of the flag)

The way I fixed my version of the driver was to use two flags, one to say
that the device/task was active, and one to say there are queued requests
to the device.  Then near TermIO (I think) I would check the flags and
potentially wake-up the task.

If anyone's interested, I can get at my code and explain in more detail
(hopefully more understandably also).  I should note that I never had
any problems with a fast device like ramdev.asm, I only seemed to get
into trouble with my (slow) software-driven IOMEGA/SCSI drivers with
multiple tasks beating-up on them.

By the way, I have a question about the SCSI direct definitions in
devices/scsi???.h/i:

The definitions for SCSIF_READ and SCSIF_WRITE seem a bit strange.  Since
the trailing prefix letter is 'F', I'm expecting this to be a mask
(rather than 'B' signifiying a bit number) Having two names seems to
imply some independence, yet the definitions of 0 and 1 implies
mutual exclusion (as long as they're masks)  If they're bit numbers, then
could BOTH be active for the same call?  I don't know of a SCSI
transaction which both reads and writes data. (But then all I have are these
ancient Alpha-10 drives, so maybe current SCSI can read & write)

Currently I'm using flags & SCSIF_WRITE as my read/write indication, 
but I'd like to know if I'm incompatible with the rest of the world.

--
------------------------------------------------------------------------
Scott Townsend               |   Phone: 216-433-8101
NASA Lewis Research Center   |   Mail Stop: 5-11
Cleveland, Ohio  44135       |   Email: fsset@neptune.lerc.nasa.gov
------------------------------------------------------------------------