Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!agate!helios.ee.lbl.gov!nosc!humu!uhccux!munnari.oz.au!olympic!enno
From: enno@olympic.oz (Enno Davids)
Newsgroups: comp.sys.amiga.tech
Subject: help with disk/tape device driver(s)
Keywords: device drivers, message ports, tasks
Message-ID: <1006@olympic.oz>
Date: 25 Jun 89 15:00:24 GMT
Organization: Olympic Amusements, Melbourne, Australia.
Lines: 62


A couple of quick questions for the net about device drivers. I am building
a set of device drivers based around a piece of SCSI hardware. To access
the hardware I have built a server process which opens a public message port
and accepts messages which contain a pointer to a SCSI command block pointer,
a data buffer pointer and some housekeeping and puts them out on the SCSI
bus for any device drivers which send it such messages.

The first problem I have is I would like to kick off the SCSI server
process from inside the a device driver if it starts but cannot find the
server process' port (and presumably thus the server isn't running). As I
understand it I cannot make any requests that result in use of AmigaDOS
either directly or indirectly. So precisely, what can I do and what can't
I, and is there a good way to start my server process (presumably from the
Init code of device driver).

The second question I have is a little more complicated. In order to
PutMsg the message to the server process I need to supply a reply port so
that the server process can ReplyMsg the message sucessfully on completion
of the SCSI command. The reply port has in it a task and signal to that task
to use to complete the WaitPort that the device driver will do after the
PutMsg.

The first version of the code I wrote allocated a reply port in the device
init code. This inherited the task and task signal of the client process
that caused the OpenDevice to load the driver. This code broke when the
driver first caused an I/O request to queue internally and hence be executed
in the device drivers own task rather than that of the client process 
indicated in the replyport's task field. The system hangs at that point as
the server process ReplyMsg's the message it is sent, but the wrong task
is signalled and presumably woken while the device driver continues to
WaitPort forever. 

I could only see two possible solutions to this problem. I could somehow
open a separate reply port for each client that opens the device. It is
worth noting that this then becomes a problem as multiple clients can
quite happily open the same device and/or unit and tracking ports for
each client can become quite complex.

The second (simpler) solution that occurred was to write my own version 
of the standard CreatePort routine to ask for a specific signal rather
than any available signal. This, together with judicious use of FindTask(0)
should allow the server process to at least reply sucessfully. (i.e. All
clients of any particular device driver use the same signal, recorded in
the reply port structure, and can set their task at the time they send their
message to the server process) A question here becomes what should I do if
I cannot allocate the requested signal when a client opens a device/unit?

I have a version employing the second solution running although I have
not as yet 'torture test'ed it or otherwise satisfied myself of its
safety. My real question here is whether or not there is a better answer
to the problem or even a 'correct' solution.


In anticipation,

Enno.


-------
Enno Davids	   Olympic Video Gaming P/L,  1562-68 Centre Rd, Springvale 3171
enno@olympic.oz	     Phone: (03) 562 4255       Fax: (03) 562 4889