Re: Just my 2 penny worth..

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

>> Who says that STram can't be virtual? You're assuming that you're going to
>
>I do. The definition of ST RAM is that it is compatible with things like
>screen and audio DMA.

That would all be emulated by the kernel and the virtual machine you'll be
running under. In reality, the memory being used may or may not be real
STram, it doesn't matter.. the kernel's virtual peripheral interface would
make it LOOK and ACT to the program as if it's STram. The kernel will set up
the memory pages, copying them into contiguous STram and then running the
real peripheral, such as the sound DMA or interacting with the Falcon's DSP
etc.

>> >> The problem is that these programs are basically a TSR the system has no
>> >> control over.
>> >
>> >What kind of control would you need?
>> 
>> Disk access scheduling, buffering etc. As soon as you give control to the
>> hard disk driver software you've handed the whole system to it. It could
>> block and halt the system until the I/O has completed or not, you just don't
>> know.
>
>Well, you do know. You just have to use the right driver.

So, you'd better document precisely which versions of which driver are
supported with MiNT and tell everyone who can't easily get access to them to
go fly a kite then?

>> Stopping processes going for the hardware or directly to a 3rd party disk
>> driver should help protect against the spread of boot-sector viruses by
>> auditing processes' disk accesses and only allowing those programs "allowed"
>> to access such things to do so. Something only the operating system can do.
>
>Yes, but this doesn't have anything to do with the changes you suggest
>(see FreeMiNT 1.15 for security extensions).

I've been following those.. they are a step in the right direction, but they
don't work with every program, even those which do stupid things. What I
propose should allow pretty well all programs to run, unless they do
something really nasty, in which case the program should be binned anyway.

>> >> I can't prove or disprove it other than saying that Sun 3/80's can do it
>> >> faster with the same SCSI controller and very similar hardware to the TT030.
>> >
>> >Yes, we all know that the NCR can do more. But both TT-DMA and
>> >Falcon-DMA
>> >can't.
>> 
>> So, use polling instead! Sometimes this can be faster than DMA anyway,
>> especially if you're having lots of other memory accessing happening at the
>> same time.
>
>Even if this *would* be faster, there wouldn't be background DMA
>anymore.

No, it would be background polling instead. This stuff would all be hidden
from programs anyway.

>> I didn't know about that. And a Demo version isn't really a good test of a
>> full product.
>
>Well. That's hard to say unless you go to Uwe's web page and find out
>what the restriction is.

I may just do that.

>Please explain in which way the AHDI 3.0 interface has any problem
>with foreign file systems, big disks and so on.

I'll have to go away and read my AHDI docs again for specifics.. it's been a
long time since I read them.

>Regards, jr

Steve

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