Re: Just my 2 penny worth..

[Stephen Usher <Stephen.Usher@earth.ox.ac.uk>]

>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:]
>> 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.

I'm afraid that you missed the point here.. this is a different thread from
the hard disk driver problem, this is the program/system protection problem.

I just chose a common use for DMA, it could just as well been an example of
two programs trying to use DMA to the sound system on the TT. The point is
that in a protected environment nothing but the kernel should have direct
access to the hardware.. and in a full virtual memory environment only the
kernel knows where the memory the program is using actually IS anyway, so it
HAS to do the I/O for the process so as to translate the virtual address to
the real one.

And on the subject of using the old disk drivers.. if the system has
basically been re-initialised with a fully virtual addressing system, the
old drivers will not be able to interact with the new programs trying to
access them as the new programs would be passing virtual addresses and
wouldn't have direct access to the driver anyway as it would not appear in
their memory map anyway.

>> 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.

See above.. the old driver couldn't really work properly as it would be in a
ROM-TOS environment which would disappear from under it once MiNT got into
the full swing of things, unless you made some unholy kludge. The only way
to use it would be to somehow reload the driver after MiNT had started,
giving it special privilages to access the hardware and locking the pages
into contiguous memory, making the virtual addresses the same as the
physical.. and even then I'm not sure how other programs could access it
other than by the kernel forwarding on the requests. Remember, by this time,
all you know about TOS memory management has totally gone out of the window,
you're in a totally different mode of operation, ALL programs but the OS are
seeing an illusion of what the system state is.

The only way around the kludge would be to ask one of the developers nicely
if we could include a modified version of their code into the kernel, or
borrow drivers from elsewhere or write them from scratch.

As for the XHDI interface, there's no problem with giving the user processes
the same interface as that all helps with compatibility with old programs.

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

Maybe, but a user program can always subvert this by going straight for the
hardware and doing all its disk access directly.

>> 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.


-- 
---------------------------------------------------------------------------
Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
E-Mail: steve@uk.ac.ox.earth (JANET) steve@earth.ox.ac.uk (Internet).
Tel:- Oxford (01865) 282110 (UK) or +44 1865 282110 (International).