Re: Just my 2 penny worth..

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

First of all, let me apologise for taking so long to reply.. I was out of
the office yesterday.

>> The problem is that these programs are basically a TSR the system has no
>> control over.
>
>What control do you need?
>
>There is a clearly defined interface between the disk driver and the rest of
>the system.

True, but the rest of the system has no control over how the driver does
things such as queueing and the interleaving of requests to/from multiple
devices on the SCSI chain. ie. You can't disconnect from a device whilst
it's doing a slow operation (useful for a scanner or laser printer) and then
get on with some other SCSI operations, reconnecting with the former device
after it's finished what it was doing.

>> 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.
>
>The TTDMA limits the throughput, not the 5380 SCSI chip - so what? You won't
>reduce this overhead by putting the driver code in the kernel itself - you
>will only introduce new bugs and throw away years of expecience from the
>people writing these drivers.  

But what you can do is select how you operate the SCSI controller on a per
device basis and also depending on the type of machine. On some machines,
after all, polling the device may be faster than using the TTDMA chip. Add
to this the ability of the kernel to do prioritised queueing of SCSI
requests (ie. page swapping has a higher priority than normal file
operations) and interleaving or data requests to multiple SCSI devices and
you you start to see that a disk driver designed for a serial processing
system is not really up to the job, if you want any sort of performance.

If you're worried about experience.. ask the people if they'd like to
contribute.. add to that the experience that the Linux/68k guys can probably
add, this shouldn't be a huge problem.

>And you need to supply drivers for all kinds of hardware that is supported
>by current drivers - that includes ACSI, TT SCSI, IDE (on Falcon and ST),
>IDE with busmastering (on Milan), PCI-SCSI (on Hades and Milan) - plus maybe
>ATW and others which I forgot. And you have to supply a SCSIDRV-interface
>(including ATAPI-emulation), so that we can use existing applications like
>GEMAR, CDRecorder etc.
>
>All this looks like quite a bit of effort for - well, for what?

Most of this has been implemented elsewhere, the source for which is freely
available. It would just have to be adapted for the new kernel.. and as the
new kernel hasn't been designed yet, it means that you can borrow someone
else's device driver interface and use that.

>> which the kernel has full control and can go straight for the hardware,
>> hence speeding access up (in theory).
>
>That is a theory which you should support somehow. I don't see how you can
>speed it up against the current scheme, which is quite simple and
>straight-forward.

But that is both its strength AND its weakness.. it's simple, yes, but it's
not designed for a fully multiprocessing environment, which MiNT is supposed
to be striving towards.

>> >c) What about HDDRIVER, HuSHI and CBHD?
>> 
>> I have no access to these, so I can't comment.
>
>CBHD is freeware - look for CBHD502.TOS.

Okeydoke.. thanks for the info.

>> 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. :-)
>
>That is a problem with the driver you used, not with the concept itself.
>
>> Someone's obviously found a way to catch illegal instructions and to emulate
>> code in Supervisor mode then.
>
>Which should not be a big problem - even if you need kernel support for it:
>DOSEMU in i386 clearly demonstrates that this can be done and that it works
>quite well - it can even execute the video BIOS ROM and boot up a native DOS
>in a virtual machine, including graphics applications.

Remeber, the x86 architecture is VERY different from the 680x0 one..
something which is easy to do on one can be hell to do on the other.

>> 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.
>
>What parts do you want to throw away then?

(1) Reliance on ANY of the old TOS code.
(2) The notion that programs should have the right to meddle with the
	hardware directly without the system having a veto.
(3) The notion that the currently running program can do what it likes.
(4) The BIOS device drivers.. new ones need to be developed which suit a
	multi-tasking environment.

>GEMDOS is almost (totally?) gone with the new (V)FAT code, and the VDI and
>AES on top of MiNT can be replaced. All that remains is the hardware
>dependant (X)BIOS and other hardware-dependant lowlevel driver stuff. Part
>of that (HSMODEM) could be integrated in MiNT, but rewriting bg parts just
>to have a new interface is not worth the effort IMHO.

Why not rewrite the serial port stuff from scratch, learning from all the
mistakes which have gone before?

The API would have to be modified slightly in a compatible way to handle the
higher speeds.. The API isn't really the issue here.. it's the stuff
underneath which REALLY matters.

>cu
>Michael

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