[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mint-aware HD driver
Claus Brod <clausb@hpbeo79.bbn.hp.com> writes:
>> I was thinking about the problems with interrupt driven HD drivers,
>> that cause mint not to block while doing disk access.
>> One problem is that we would need a kind of semaphore for the dma hardware
>> as it has to be locked against duplicate accesses at the same time.
>
>This is not a problem at all if we have a general /dev/scsi driver.
>In this case, any process that wants to access SCSI hardware
>directly would Fopen() that driver, and MiNT could apply its
>usual restrictions against multiple access. We don't need semaphores
>if there is only *one* official SCSI driver. Such a driver should,
>however, probably have a Fcntl() mode to query its status, i.e. if
>the SCSI channel is currently used by it.
>
>> What do you think about it?
>
>I think this is one of the less important problems. It's much more
>important to have a reentrant GEMDOS, or else the whole project
>comes to a grinding halt. That's exactly the point where my own driver
>currently is. I haven't found the time yet to implement such a thing
>in the MiNT kernel myself.
I don't think it's strictly necessary to re-implement GEMDOS right now -
simply putting something like
Psemaphore(2,'GEMD',-1L) ; /* request GEMDOS Semaphore */
/before/ and something like
Psemaphore(3,'GEMD',-1L) ; /* release GEMDOS Semaphore */
/after/ any GEMDOS calls in tosfs.c should protect GEMDOS from any
reentrant calls.
Or are there some hidden problems I'm overlooking?
--
Martin Koehling | mk@anuurn.do.open.de | Martin_Koehling@un.maus.ruhr.de