RE: AW: [MiNT] analysing syscall.spp

["Julian Reschke" <reschke@muenster.de>]

> From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> Of Johan Klockars
> Sent: Sunday, April 18, 1999 5:13 PM
> To: mint@fishpool.com
> Subject: Re: AW: [MiNT] analysing syscall.spp
>
>
> > > FN>It's not a good idea to make the complete GEMDOS callable from an
> > > FN>interrupt.
> > > I don't even think that it's possible for all calls.
> >
> > Well, MagiC for some degree proves that it is possible.
>
> Note that it said 'all calls' above.
> What would MagiC do if a potentially blocking call, such as a semaphore
> wait (or for that matter some file system things) was called from inside
> an interrupt?

Sorry, I misread. MagiC is fully reentrant, but that doesn't mean that
everything can be used from an interrupt.

> Under MiNT, none of the routines that rely on the original TOS could be
> called from interrupts either, of course.
>
> Making it safe to call MiNT from interrupts will require that interrupts
> are disabled here and there in the system, but that (or semaphore
> locking, but then we _really_ need faster semaphores) is needed anyway if
> the kernel is to be reentrant at the process level.
>
> > > Especially for the file system calls it should be very difficult or
> > > impossible (and not worth the work)
> >
> > Then you won't be able to make use of background DMA.
>
> Why would you need to use the file system for background DMA?
> I don't know how the mechanism in HDDriver work, but it can hardly
> be file system level, since that's handled by MiNT/MagiC drivers.
>
> It could work something like this, for example:
> 1 The file system tells the device driver (HDDriver) that it wants to
>   transfer a block of data and be notified when it's done.
> 2 The FS code blocks on a semaphore or similar, thereby leaving all
>   processor time for other tasks.
> 3 When a transfer is completed, the device driver wakes up the FS again,
>   which may initiate another transfer (goto 1) or return to the caller.

Yes, but that does mean that even with background DMA, it wouldn't be
possible for a second process to use the file system while another process
is accessing the file system. That would be a major problem as calls would
be blocked even when they don't have to (like: process 1 is reading from
floppy disk, process 2 needs to access data on a TT-SCSI device, process 3
is accessing data which is already cached and so on...).

> Step 1 might require a call to a variation of RWABS (XBIOS).
> In step 2 it would obviously be best if as much of the operating system
> as possible is still callable. Some semaphore protection on the actual
> disk read/write routines might be enough.
> Since HDDriver is not MiNT-aware, I guess the way to deal with step 3
> is to make the file system code wait for the 'DMA-complete' interrupt
> itself. IIRC, MiNT already can treat interrupts like signals, so it should
> be possible to handle that.
>
> None of this require any OS calls whatsoever from an interrupt handler.

Yes, I agree.

MagiC just offers 3 calls each for the two DMA interfaces of the Atari
(DMA/NCR): obtain semaphore, wait for interrupt, release semaphore. HDDRIVER
just uses this kernel interface, and it would make Uwe's life much easier if
MiNT could provide a similar interface...