From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 29 Dec 1997 12:25:45 -0800 From: Eric Dorman eld@jewel.ucsd.edu Subject: [9fans] Re: etherelnk3.c Topicbox-Message-UUID: 6ec0f08c-eac8-11e9-9e20-41e7f4b1d025 Message-ID: <19971229202545.cV2RIPPWdviUf2SUvqkxHNu3aFuuAr9DIxgZfQnS50Y@z> > >From: eld@jewel.ucsd.edu (Eric Dorman) > >> From: "G. David Butler" > >> 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" > 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