Re: Documentation on minixfs and ext2fs

[steve@mctavish.demon.co.uk (Steve Woodford)]

> >is already well tested. It's also re-entrant, so unlike minixfs
> >we could wave goodbye to 'busy-waiting' for disk transfers...

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

Perhaps I'm misinformed about MinixFs, but I do recall a warning in
a README file with Erling Henanger's ehscsi package about using it
with MinixFs. I just assumed it was because of re-entrancy problems.

I too am surprised it hasn't been done already, but then most people
who would be bothered seemed to have moved over to Linux-m68k on TT's
and Falcons. I still don't believe MinixFs would work "as-is" though,
I have serious misgivings about re-entrancy in the cache code.

> I think it should be possible to trap the BIOS call, maybe wait
> a clock tick or two for the disk IO, and if we're sitting in a
> BIOS call for longer than that, then use the timer tick to switch
> tasks - and don't go back to the busy loop until an interrupt has
> hit - that and proper locking by redirecting the BIOS calls and

Maybe, but a better way might be not to use the BIOS at all. I'm
thinking more along the lines of a scsi.xdd for disk access, among
other things.

> I WANT non-blocking disk IO - BADLY.  And it would be nice to kill
> any other polling too!

Seconded! It wasn't so bad on the old 4Mb ST; if you're compiling
using gcc, there is no spare memory to do anything else. But with
this MVME147 (VTOS/VMiNT) having 16Mb of RAM, it's a royal pain to
have everything freeze each time a background 'make' loads up gcc!!!

Cheers, Steve