[9fans] Re: etherelnk3.c

[Eric Dorman eld@jewel.ucsd.edu]

> >From: eld@jewel.ucsd.edu (Eric Dorman)
> >> From: "G. David Butler" <gdb@dbSystems.com>
> >> To: 9fans@cse.psu.edu
> >> Subject: [9fans] Re: etherelnk3.c
> >> 
> >  Another thing to consider is how these changes would affect
> >the integration of ether drivers between the fs and terminal code.
> >Integrating these two trees first allieviates a whole mess of 
> >existing problems and ensures that this type of effort won't 
> >have to be done again (perhaps differently, even) for fs.
> 
> In fact the problem becomes worse since Blocks don't exist
> in the fs.  There we would have to use Msgbufs.
> 
> From: "jim mckie" <jmk@plan9.bell-labs.com>
> Subject: Re: [9fans] Re: etherelnk3.c
> 
> actually, it's easier. you can turn a Block-based driver into
> a filesystem driver with a handful of #defines, two trivial functions
> and a couple of #ifdefs (i know, we don't actually approve of that).
> #ifdefs are only necessary because Blocks use read and write pointers
> and Msgbufs use a base and count.
> --jim

Definately worth a look; I've got a 9pcfs that allows the use
of IDE disks for filesystems and have found that the network
is far and away the limiting factor (10Mbit/sec 10BaseT on NE2000s)
and 100BaseT is practically free these days; I'd love to use 100BaseT.
I have some BayNetworks DEC21140 100bT PCI cards (plus the chipset docs)
but haven't got around to scribbling out a driver with
the holidays and all :)

The IDE interface is pretty crufty and sits on top of the primitive
hardread/hardwrite interface in hard.c.  I have just one more nasty
bug to stomp before exposing it to the outside world (screwy IND1
block tag problem?).  It really deserves a better driver to take
advantage of LBA, multiple read/write commands, and etc; maybe
next week.  Might even be able to interleave across primary and 
secondary IDEs (if the braindead chipsets will support it..).

So far I've had to scramble around in the fs code changing 'long's
to 'ulong's in bytewise size computations and changing the type
of disk block addresses to ulongs; the matched-pair of 3.5G disks
breaks 'long's.  I'm worrying though that this may have caused
my block tag bug. 

I'm pretty sure I've got all the dots connected but still get 
bitten by this tag bug.  It crops up when writing a big file
into the fs (typically ~19Mb), then writing another big file;
the first file, when reread, causes errors like
 'tag 5 -- expected 3 -- flushed' when reading IND1 blocks
and a read error on the terminal.  How I read this is that the fs
reads a block, expecting it to have tag 3 (IND1 block) but instead
got a file data block (tag 5, err DFile); I'm pretty sure the block 
in question *should* have been an IND1 block but I haven't actually 
seen the fs scribble on that particular block any time after it 
gets flushed for the first time.  (Grr) It appears the right 
physical sectors are being read/written, but I haven't
fully internalized the byte-offset/length weirdness in hard.c
enough yet to be fully convinced everything works under all
conditions.

I would like some comments on changing the way the fs knows
about available physical disks.  As it stands the fs knows
about 'Devwren', 'Devworm' and etc. which is fine.  The choices
for adding an IDE interface were to utilize a new dev type
(Devide) and codeletter (h) for IDE disks, (requires rewiring
stuff in fs/port/sub.c) or somehow patching into the scsi
stuff below the Devwren level.  I chose the former as an
easier solution but it's, well, icky; changing stuff in
fs/port is evil since I'd have to stub out 'ideread/idewrite'
in all other architectures.  

Seems to me a better solution would be to have the hardware-specific 
initialization stuff build a table describing the disks connected
to the box (complete with codeletters, size, traps into the
hardware driver, etc) and have fs/port/sub.c go indirect
through the table to the hardware.

Sincerely,

Eric Dorman
edorman@ucsd.edu