Re: Just my 2 penny worth..

[Julian Reschke-FJR010 <Julian_Reschke-FJR010@email.mot.com>]

Stephen.Usher@earth.ox.ac.uk%INTERNET wrote:
> 
> >I must admit that I don't understand. ST RAM can't be virtual by
> >definition. And if somebody does an Rwabs to TT RAM, it's up to the
> >virtual
> >memory handler to remap the call, and this is what Outside does.
> 
> 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.

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


> >> >c) What about HDDRIVER, HuSHI and CBHD?
> >>
> >> I have no access to these, so I can't comment.
> >
> >CBHD is freeware, HDDRIVER has a free demo version.
> 
> 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.
 
> >> It's more of a problem with the drivers and/or TOS getting confused with the
> >> filesystems before MiNT starts.. this can cause either TOS or the driver to
> >> crash. Just try using a Linux ext2fs partition with a driver which doesn't
> >> allow you to turn partitions off from TOS's point of view.. from what I can
> >> remember, TOS 3.05 gives 4 or 5 bombs. :-)
> >
> >Well. Yeah. Great. That's a bug in the harddisk driver you are using.
> >Use a better one. But there's no reason to change the harddisk driver
> >interface just because you happen to use one which doesn't work
> >properly.
> 
> What I'm saying is that the current interface is clunky and ill suited to
> the modern environment.. it was a hack, a quick fix to get something out of
> the door which worked but wasn't pretty.. there ARE better ways to do
> things, why not take advantage of them?

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

> Also, having people use lots of different hard disk drivers underneath the
> kernel will make it hell to support. Yes, and support IS important. If
> everything's under control then you don't have to have lots of tests in the
> filesystem code to operate work-arounds for specific hd drivers, making the
> code smaller and faster.

I would welcome if any kludges for non AHDI compatible drivers would
be removed. But hen we still can run AHDI, CBHD, HDDRIVER and HuSHI.

And so on...

Regards, jr