Re: Documentation on minixfs and ext2fs

[ekl%beastie@sdf.lonestar.org]

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

Hmm .. I remember a patch for Minixfs that would patch Minixfs to
use the ehscsi driver instead of BIOS, however, I seem to recall
that the driver would only work on some systems (not ACSI) and
there were certain other limitations.  I forget the details and
I don't seem to have the code on my drve anymore.

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

Hmm ... I think we need to get a raw driver going first, and then
worry about the rest.  Even if we have to add blocking/wait code
to the Minixfs driver to prevent concurrent access, it would block
the filesystem instead of the entire machine!  Getting that non
blocking driver is first - re-entrancy second.

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

Well, I realize that.  Its a MUCH better method to write a real
driver, however, I don't know the details of the ACSI port well
enough to attempt it (or the details of controlling a LinkII or
something from the ACSI port).  I think everyone was just kinda
sitting back and waiting for someone to write the driver.  I think,
that a more drastic change internally is more in order.  Instead
of letting the BIOS block, we should take the BIOS back after the
next tick, pre-empt it, semaphore lock it, and then get on with
other tasks.  This would mean pre-empting the BIOS, and would
mean pre-empting a supervisor process.  

Well, who wants to write to write the new Rwabs() wrapper?

CYA,
Evan Langlois