Re: GEMDOS re-entrancy

[Juergen Lock <nox@jelal.north.de>]

Evan K. Langlois writes:

> ========================================================================
>  (hmm i didn't that one..)  on MiNT console IO has nothing to with GEMDOS,
> for MiNT GEMDOS is just a bugged messdos-filesystem with clock. :)
> ========================================================================
> 
> I was under the impression that parts of MiNT were not re-entrant.

 true.  hmm i begin to see the confusion here...  when i think of
re-entrancy i think of real-time OS or things like doing systemcalls out
of interrupts etc.  MiNT, like TOS, (and i'd say also still most unices)
is no real-time OS and the only parts you can safely call from `anywhere'
are wakeselect and addroottimeout. (i think.  maybe a few more...)

 but this does not mean you cannot sleep for disk IO, like it also
doesn't mean my editor has to waste CPU time polling the tty for the
next key or even halt the whole system. :(  sure it will need some
hacking but i don't think we have to turn MiNT into a real-time kernel...

>  If you
> can open files and such on a Minix drive (without calling the ROM GEMDOS)
> and all the functions to do so are re-entrant, then why block GEMDOS when
> you could just make a real TOSFS that doesn't call the ROM.

 sure if you don't want to port a real BSDfs, linux ext2 or something
instead...  i.e. why not make something _better_ than V2? :)
> 
> Otherwise, what parts of MiNT aren't re-entrant?  Time functions could be
> allowed to block, as most other things, as long as disk IO doesn't lock the
> whole system.

 hmm Tgetdate/time is called quite often, MiNT should better keep the
time itself...

>  As for DMA hard disk IO having problems with the BLiTTER,
> isn't there a semaphore for this?  Yeah, here it is, flock @ 0x0000043E.W

 is that used for `real' SCSI IO (TT) and IDE too?
> 
> Hmm .. if rwabs were to be replaced by a call that puts the call on a wait
> queue, and then waits for an interrupt (and maybe a timeout??) what interrupt
> would it wait for?  What is the DMA "complete" interrupt?

 ACSI/FDC is a bit on the ST 68881... (i'd have to look it up but i guess
claus knows these already :)

>  I would guess
> that any "SCSI driver" would replace rwabs and install into  ... I guess
> all the hdv_ vectors located between 0x046a and 0x047e?

 i'd say `real' generic [AS]CSI devices would go in /dev?  maybe the
disk layer can hook into the hdv_* for compatibility...

> A real hard disk driver is beginning to sound like a more complex version
> of /dev/lp or the modem devices, but it would follow the same principles
> right? 

 yup!  theres no principal difference between these and disk IO, or
other SCSI devices such as laserprinters, tapes... (btw anyone has a
decent tape driver for me that works on the ACSI port? :)

> Hmm .. as for locking the AES and VDI when they make a call that would
> normally block the system .. how about we see if it needs it first.  There
> is a good chance that locking GEMDOS will be sufficient, and having another
> application open a window or something like that before the AES is done
> loading fonts for another app, just might not cause any weird effects. There
> is always wishful thinking.  Or, there is a real easy and compatible method
> in this situation .. when the AES or VDI makes a GEMDOS call, lock the
> whole system up again :-)

 well i _think_ locking (== sending to sleep) AES+VDI calls then is enough...

>   Atari should give us the source code to AES and
> VDI so we can see what exactly is re-entrant and what isn't :-)

 and fix all the bugs...
> 
> Hmm .. how many DMA channels does the STe have?  There is DMA sound,

 (integrated with video DMA)

> DMA hard disk,

 and FDC (floppies) use the same channel

>  and DMA BLiTTER ... and on a Falcon aren't the SCC ports
> DMA??

 i think only TTs have these...

>  I know the Falcon has separate channels for sound.  Are the STe's
> sound DMA channels separate from others?

 yup

>  What about floppy access?  IS
> that doomed to lock up the system?

 not more than ACSI disk if you write a new floppy driver.  except
that it'll block its channel a bit longer probably, given floppies
access time and data rate... :)

 cheers
	Juergen
-- 
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
								...ohne Gewehr
PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA