[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mint-aware HD driver

> >Not bad, although I'm concerned about the overhead that such a split
> >driver would cause. But anyway, the driver's design is not the main
> >problem, as I mentioned in my previous post.
> Far less overhead than the current busy idle until transfer is complete type
> HD drivers.

That's right, but I would implement it monolithically to save some
time for passing parameters; I recently did something similar in
my own SCSI driver, and it sped up the transfer of small blocks
by several times ...

> Hmm.. GEMDOS is a bit of a problem, but it's not that complex to
> reimplement. In fact a lot of it IS reimplemented in the current MiNT
> kernel! All it would need would be for the GEM filesystem part to be
> reimplemented, the rest is being used in a multitasking mode at the moment.

The most simple method would be to put all callers but one 
of GEMDOS functions into a queue that is emptied when an I/O
transfer completes.

Claus Brod, MDD, HP Boeblingen      Magic is real unless declared integer.
--#include <std_disclaimer>-----------------------------------------------