Re: Just my 2 penny worth..

[Michael Schwingen <rincewind@tubul.dascon.de>]

On Fri, Jun 26, 1998 at 10:03:11AM +0100, Stephen Usher wrote:
> >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.

That *is* possible - The combination of CBHD and GEMAR gets a lot more
performance out of the TT SCSI bus than from a ST ACSI bus, due to
disconnect - I get streaming on a HP 35480 DAT (12MB/s plus compressions)
even when backing up many small files, which is nearly impossible on a ST.

You can't control it - however, that is the case with all drivers: the
driver is a black box which handles the hardware - *he* knows how to do
this, and everyone else simply has to use the defined interface - inclusing
the kernel.

> 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

If you think so - then modify a harddisk driver to do this. We need no new
interface for this.

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

This might require some extended interface to the driver. However, I still
do not see why we have to throw away the existing drivers completely.

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

What source are you talking about? Linux?

Have you tried adapting an existing Linux driver to a completely different
environment?

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

So you want a more complex interface, and you say that you can speed it up
at the same time? This sounds a bit strange ...

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

The 680x0 does not have something like the virtual 8086 mode of the i386+,
but a completely virtualized environment should provide everything that is
nevessary on 68030 and above.

cu
Michael
-- 
Michael Schwingen, Ahornstrasse 36, 52074 Aachen