Re: Documentation on minixfs and ext2fs

[ekl%beastie@sdf.lonestar.org]

First, my apologizes to the list for posting blank or redundant mesages.
I keep hitting ~. instead of ~f or ~v.  Anyone familiar with mailx
will know those commands.  I need to get elm and a good mailer - but
not for another couple weeks.

>However, I did write an ACSI based scsi library a while back which should
>be on a.a.u.e in the Programming directory (non-mint). If I recall, it's
>called libscsi1.[tgz/zoo] or something like that. It contains low-level
>ACSI code in it, plus a higher level SCSI command interface. Now, if
>someone wants to volunteer... ;-)

Hmm .. very interesting.  

>The only fly in the ointment is that it's not interrupt driven, though it
>could be easilly converted. The problem is that the floppy drive uses the
>same DMA interrupt... :-(  Your solution (below) would not need to be
>DMA interrupt driven.

Yes, it does, and AFAIK, we only have 1 DMA channel, right?  What
happens with BLiTTER IO?  We might need to lock that too!  Speaking of
which .. if the DMA is busy, would it be better to use the TOS software
routines for a bit-blit, or just lock any process using the BLiTTER
as well?  A long disk IO might make it better to use a software blitter
routine when DMA is busy.  Hopefully we won't need to bother with the
BLiTTER at all.

>Hmmm, two semaphores would be needed, one on RWABS and one on MinixFs.
>I recall that the ROM BIOS RWABS (trap #13) isn't used on MiNT since the
>kernel has it's own version which vectors through the hdv_xxx routines.

You mean one semaphore, set in both places?  I think that the BIOS
Rwabs is redirected to the MiNT version (or could be redirected that way),
then we only need to mess with the MiNT version of RWABS.

>The actual drivers (eg. ICD) use the 200Hz tick to implement a timeout
>on the busy-wait for DMA completion, and also the busy-wait between
>SCSI command bytes. The command byte timeout is very short so we would
>have to be *extremely* careful not to pre-empt RWABS too soon otherwise
>the driver would continually timeout. The main completion timeout is
>fairly long (a few seconds at least), so isn't quite so susceptible to
>being pre-empted. Someone's going to have to be pretty brave to mess
>with RWABS on a live system!! B-)

Hmm .. that could be tricky depending on how the driver is written.
I guess we could just give the BIOS a full slice or maybe two or three
of them before pre-empting it.  Or, maybe not give the driver 200Hz
ticks unless we want to give them - and maybe fake them.  Either way
sound complicated.  I'd like to see your libscsi code.

>> Well, who wants to write to write the new Rwabs() wrapper?
>
>Not me, that's for sure!!

As for a live system - I have an extra MegaFile 30 I could stick MiNT
and shell on and see use it for testing.  It would mean taking the
system up and down 20 times though - or putting more RAM into the
520STFM I have and using that as a complete test system.  Darn.
I'd hate to scrap a partition table on my 540MB SCSI :-)  O rsend
some command that tells the Link II its a parity drive or some other
weird thing and fry everything.

I'm not too familiar with MiNT interrupt handling and wake/sleep stuff
to do it myself though.  Any volunteers?