Re: Just my 2 penny worth..

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

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

Precisely my point! The kernel is supposed to be in FULL control of the
system.. if it then goes and farms out some of its responsibilty to some
black box it has no control over then it ISN'T in full control.

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

Not at the user level you may not.. but down below where the OS has to work
there definitely is.

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

See my previous message.

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

Possibly. Or *BSD etc.

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

Well, as the kernel's driver interface hasn't been designed for this
possible project anyway, you could always just define the interface to be
the same as that of another system and hence use all their hard work.

Thinking about it.. more and more you could use the Linux kernel as a basis
for the new MiNT.. remodelling the memory management and system call stuff
so as to create a TOS orientated system and binning all the stuff we don't
need.. such as support for PCs, Alpha boxen etc.. but it would allow us to
stand on the shoulders of others to reach the stars.

However, it would mean dumping the 68000 people if we did that, which is
something we should avoid.

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

Complex but integrated, below in the kernel, which is doing complex things
already.. from the API nothing needs to change.

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

But we need to support the 68000 people too.



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