Re: Just my 2 penny worth..

[Michael Schwingen <rincewind@tubul.dascon.de>]

On Fri, Jun 26, 1998 at 10:15:28AM +0100, Stephen Usher wrote:
[quoting completele, since he asked me to forward a copy to the list - his
article missed a Cc:]

> >The kernel *does* know when a DMA operation starts - it would have to
> >virtualize all hardware accesses (just like Win95 does :-)) - then it could
> >copy the DMA data to a contiguous block and lock that one *before* starting
> >the DMA transfer.
> >
> >However, this looks like too much effort to me, providing little benefits.
> 
> You've forgotten one possible very major benefit..
> 
> DMA queueing and locking and vetoing in a multitasking environment.
> 
> Just think of the following senario:-
> 
> 	Program 1 starts a DMA from the ACSI.
> 	Program 2 tries to start a DMA operation to the Falcon IDE.
> 
> You can't do them both!

Falcon IDE can't do DMA, so there is no problem doing both at the same time.

The only DMA-capable IDE port I know of in an Atari-compatible machine is in
the Milan.

> Solution..
> 
> 	Kernel sees the conflict, puts Program 2's DMA request into the
> 		queue.
> 	Program 1 completes its DMA.
> 	The Kernel initiates Program 2's DMA for it.
> 	Everyone is happy! :-)

This can be done fine using existing harddisk drivers. We may need an
additional interface for some of the functions - note, however that
something like this exists for Magic since a long time, which enables at
least background DMA using CBHD and HDDriver (Hushi?). I still see no need
for a complete new interface and complete new drivers - only possibly
modifications to the existing one.

> Senario 2..
> 
> 	Program attempts to access a DMA device in a way in which it has
> 	been deemed illegal (eg. a virus tries to write to the boot sector
> 	of a SCSI disk).
> 
> 	The kernel gets the DMA request.. sees that it's something which is
> 	not permitted and does a pre-defined action.. either giving the
> 	program an error or killing it.

This can be done just now - every disk acces goes through the kernel (how
about XHDI? The kernel could easily wrap these) - no need for modifications
on the driver side.

Actually, HDDriver can do just this: write-protect the boot/rootsectors.

> Remember, to have a fully safe (for other programs) multi-tasking system
> running code which was designed for a single-tasking environment, you need
> system protection as well as memory protection.

Right. However, I still don't see an argument why this can't be done using
existing disk drivers.

cu
Michael
-- 
Michael Schwingen, Ahornstrasse 36, 52074 Aachen