Re: Just my 2 penny worth..

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

>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
be using an old memory model where programs "see" other programs in memory.
What I'm suggesting is that every process gets a separate virtual ST to run
under, programs all start with what appears to them to be a cleanly booted
ST, they can't tell any difference. By doing that it protects the process
from each other totally and also allows the OS to control the processes
completely, so preventing rogue processes from taking over the system.  Any
"rogue" process which tries to meddle where it's not wanted can be killed
without it affecting anything else running at the time.

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

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.

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

The Sun 3/80 doesn't have DMA for its SCSI but can manage to outperform the
current TT transfer rate, at least under TOS/MiNT. (Linux/68k seems a lot
faster too and I think they are using a slightly modified Intel Linux NCR
device driver, which would poll.)

>> I'm not.. I'm just saying that a lot of problems would be solved if the hard
>> disk driver was brought in-house and hence becomes a known quantity. One in
>> which the kernel has full control and can go straight for the hardware,
>> hence speeding access up (in theory).
>
>I don't have anything against writing a new harddisk driver which can
>do all these wonderful things -- I just don't happen to see anyone who
>is prepared to do all the dirty work.
>
>But even then there is little reason to break the existing and well
>defined interface, unless you can supply one.

Easy.. it's not clean.. it has lots of kludges to handle big disks and odd
block sizes.. anyway, you would have to fit an AHDI compatible layer on top
of the low-layer stuff for compatibility. It's just that the kernel doesn't
have to be lumbered with it.

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

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

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.

>> Maybe.. but TOS + MiNT is an even more unholy kludge than Windows 3.1 over
>> MSDOS.. it works (just, mostly) but it is klunky and could be a whole lot
>> better if it were redesigned from the ground up throwing away the 15 year
>> old baggage but keeping backward compatibility with old programs.
>
>I completely agree to get rid of TOS wherever possible, but some defined
>interfaces like the BIOS interface to mass storage are working
>completely
>fine, so why throw them away?

I didn't say to throw them away completely, they HAVE to be there for
compatibility for outside programs, but the kernel should do things at a
lower level than the public API and put the API over the top. If the
alternative exec format is implemented, those programs could be given a new
API if it's felt necessary.

>What do you do with people who have proprietary hardware which *needs*
>these drivers? CD ROMs on cartridge ports? ZIP drives on cartridge
>ports? SCSI hardware connected to a PC card in the Milan?

Fine.. integrate loadable drivers for them.. 

>Do you want to rewrite all this code? Good luck.

Sure.. if it's ST specific then it may take some work. If the devices use
industry standard components and the OS's internal driver model is close to
some other OS's driver interface then it should be quite easy to borrow
their driver code. If the manufacturer of the hardware is not open about the
way to operate their hardware then they are very short sighted. You never
know, they may like to help with the project.. after all it would make their
hardware look better too! :-)

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