Re: Documentation on minixfs and ext2fs

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

ekl%beastie@sdf.lonestar.org writes:
> >is already well tested. It's also re-entrant, so unlike minixfs
> >we could wave goodbye to 'busy-waiting' for disk transfers...
> 
> It was my understanding that the main reason MiNT does a busy-wait
> for disk IO is that it must call the BIOS to make the actual disk
> transfer, and the BIOS doesn't know how to put an app on a queue
> and wait.  Now, I'm sure there are a hundred ways around this,
> but I think if it was just a matter of making Minixfs re-entrant,
> then it would be done already.
> 
>...

well we've been thru that before, look for the `Just a couple of things',
`GEMDOS re-entrancy' thread from a while (bit less than 2 years :) ago.
i'll repost just one post below... (could dig out more if anyone needs.)

 and the only changes i'm aware of since then is a) we now have
(still experimental afaik) iwake() in the device interface which
the SCSI/ACSI interrupt could call directly, and b) there are now working
68k ports of NetBSD and linux from which maybe code could be borrowed.
(i'd look at NetBSD first...)

 hope this helps
	Juergen

~From oytix!olis.isc.north.de!terminator.rs.itd.umich.edu!mint-request  Fri May 27 11:42:22 1994
~Subject: Re: Just a couple of things.
~To: clausb@hpbeo79.bbn.hp.com (Claus Brod)
~Date: Wed, 25 May 94 20:43:26 CDT
~From: Juergen Lock <nox@jelal.north.de>
~Cc: mint@atari.archive.umich.edu
~In-Reply-To: <9405240712.AA24516@hpbeo79.bbn.hp.com>; from "Claus Brod" at May 24, 94 9:12 am
~Message-Id: <9405251843.AA00340@jelal.north.de>

Claus Brod writes:

> >  hmm, sure?  if we just want IO to halt only processes which are in a
> > disk IO systemcall (as opposed to `halt _every_ process' like its now...)
> > then we don't need real multithreaded filesystems yet, and i don't think
> > the kernel needs much more reentrancy than now like when a process
> > sleeps for tty IO.  and the SCSI interrupt handler could just reset
> > its in-service bit and ipl and then addroottimeout()?

> - Process A calls GEMDOS to read a file.
> 
> - GEMDOS calls BIOS to read a block.

 s/GEMDOS/filesystem/; s/BIOS/diskdriver/;  ok :)
> 
> - HD driver initiates transfer, puts process A to sleep. Note that
>   process A is now sleeping *inside* GEMDOS.
> 
> - Process B makes a GEMDOS call.
> 
> Similar scenarios are possible for VDI and AES calls which in turn
> call GEMDOS (vst_loadfonts, rsrc_load...).
> 
> The most simple solution would be to block any GEMDOS call when
> another process already is in GEMDOS.

 yes thats what i ment, GEMDOS is a single-threaded filesystem...

>  This would at least allow
> other processes to use the CPU or call (X)BIOS.

 and to do any other systemcalls, those that end up calling filesystems
(and GEM if process A was in GEM?) just go to sleep until its their turn.

>  Better than
> nothing.

 !!

 ok what about this:  add a flag for multithreaded to struct filesys,
if clear (tosfs, current minixfs... the kernels others are `multithreaded'
alreay) do
	while (diskdriver sleeping for IO)
		sleep (IO_Q, IO_SINGLE);
before fs calls, and when the diskdriver is done make it call
	wake (IO_Q, IO_SINGLE);
before it returns.  for GEM in trap #2 do the same
	while (diskdriver sleeping for IO and request came from inside GEM)
		...
then you can still type in windows etc. when processes do normal disk IO
not thru GEM calls.  (hmm or does the blitter confuse DMA?)

 so whats left now?  GEMDOS calls outside tosfs... (maybe that was your
problem?)  there are a few in initialisation and when leaving MiNT,
other than that i see only Sversion and some regular calls to the time
funtions.  ok if we don't want the sleep thing there MiNT has to keep
its time itself...

 thats the idea, now what did i miss? :)  cheers
	Juergen

PS:  and then make real devices for /dev and with readv/writev, use them
in minixfs, make minixfs multithreaded, port the BSD fs... :-)
-- 
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