Re: AW: [MiNT] analysing syscall.spp

[Johan Klockars <rand@cd.chalmers.se>]

> > It could work something like this, for example:
       ^^^^^                           ^^^^^^^^^^^
...
> > 2 The FS code blocks on a semaphore or similar, thereby leaving all
> >   processor time for other tasks.
> 
> 2a another task wants to access a filesystem.  
...
> still running, provided the device sits on a different physical bus.
>
> Even when the same physical bus is accessed, it may be advantageous to have
> multiple accesses come down to the lowlevel disk driver level: this is

In the notes after this I suggested that only the actual disk read/write
should be blocking, which is obviously a lot better than locking the
entire file system (which in itself is a lot better than locking the entire
OS, as is currently done).

> actually *needed* to that the disk driver and the disk can fully use tagged
> command queueing and reorder the requests in a order which provides maximum
> throughput.

You're a bit ahead of most Atari systems here, I think.  ;-)

With the limitations of the 68k series processors, I really doubt we need
to worry about people doing heavy enough work on the machines that anyone
would see a need to write device drivers like that.

> > 3 When a transfer is completed, the device driver wakes up the FS again,
...
> Which would disable all concurrent accesses to different drives, and
> (depending on where the lock is), you might even block accesses that the FS
> could handle from the caches without needing any disk access at all.

See above.

> However, as soon as we are talking about PCI cards, you have multiple
> problems:
>  - an interrupt need not mean the end of the DMA transfer - on a 53C8xx, it
...
>  - There may be multiple PCI cards sitting on the same interrupt line. In
...
> These are two reasons that come to mind that make it impossible (or at least
> a very bad idea, IMHO) for the kernel to know about interrupts ending DMA -
> the lowlevel driver has to issue the command to tell the kernel that the
> transfer is started/ended - and this *will* come from an interrupt.

So, don't use the actual hardware interrupt to wait on.
It's easy enough to fake an interrupt that isn't used by any hardware.

Naturally, anything different from the original HDDriver/MagiC background
DMA scheme will require that someone writes new device drivers...

> You might get a scheme working without kernel calls from interrupts -
> however, I think it might get a bit clumsy, and not as efficient as
> possible.

You're quite right, and I'd much rather do things the 'right' way too.
Currently that isn't possible in MiNT, though.

The main point of my message was to show that you don't need to be able
to use file system calls from inside an interrupt to deal with background
DMA, You _can_ even do without OS calls completely.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johan@rand.thn.htu.se
                        | so hard to do |  WWW/ftp:  rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (MGIFv5, QLem, BAD MOOD)