[9fans] Re: etherelnk3.c

[9fans] Re: etherelnk3.c

[jim]

	>Of course the current support in the fs is for pretty slow
	>scsi controllers, from what I've seen.  One could stick a 
	>PCI controller that looks like an AHA1542 in there but the 
	>driver wouldn't utilize 32-bit addressing, forcing the use of
	>bounce buffers...  hmm, didn't some of the VLB cards have 
	>a larger address space?

this has been gone over before on the list. given the buslogic eisa controller
driver in the fs kernel (which is no slouch), it's trivial to make a buslogic pci
controller work in 32-bit mode; that's what we use.

--jim

[9fans] Re: etherelnk3.c

[jim]

	Do the Buslogic VLB cards (445) also have this extended mode?  I
	use one as a 1542 compatible, and it seems to work ok, but I haven't
	used it with more than 16MB of RAM.

i don't have the manual handy to verify, but unless i misread it the following
comment from the driver indicates it does (i've never used a 445):

	/*
	 * Try to determine if this is a Buslogic 32-bit controller
	 * by attempting to obtain the extended inquiry information;
	 * this command is not implemented on Adaptec 154xx
	 * controllers. If successful, the first byte of the returned
	 * data is the host adapter bus type, 'E' for 32-bit EISA,
	 * PCI and VLB buses.
	 */

--jim

[9fans] Re: etherelnk3.c

[Eric]

> To: 9fans@cse.psu.edu
> Date: Tue, 30 Dec 1997 21:41:15 -0500
> From: "jim mckie" <jmk@plan9.bell-labs.com>
> Subject: Re: [9fans] Re: etherelnk3.c
> 
> 	>Of course the current support in the fs is for pretty slow
> 	>scsi controllers, from what I've seen.  One could stick a 
> 	>PCI controller that looks like an AHA1542 in there but the 
> 	>driver wouldn't utilize 32-bit addressing, forcing the use of
> 	>bounce buffers...  hmm, didn't some of the VLB cards have 
> 	>a larger address space?
> 
> this has been gone over before on the list. given the buslogic eisa controller
> driver in the fs kernel (which is no slouch), it's trivial to make a buslogic
> pci
> controller work in 32-bit mode; that's what we use.
> --jim

Yep; I did it with mine before it died due to an internal defect ( :< ).

Regards,

eric

[9fans] Re: etherelnk3.c

[jim]

	>But how do those controllers compare to the Qlogic board or
	>the Adaptec 294x?  The QLogic board has two processors like
	>the 154x and you only get one interrupt per SCSI command.
	>(like the 174x. you can get many completed per interrupt on the
	>154x.) The 2940 gives interrupts as targets disconnect/reconnect!
	>The host processor has to almost manage the SCSI bus directly.
	>A 154x will even retry a command to a BUSY LUN for you without
	>issuing another interrupt.

the buslogic, ncr and dpt controllers do everything the 154x does,
and more. ngr has answered about the ncr controllers, and i've used
them without problem. the buslogic controllers are available in isa,
eisa and pci, narrow/wide/differential. they are software compatible
with the 154x but the eisa and pci have a 32-bit extended mode. we
use one driver for all 154x and buslogic cards, the only thing it
has to deal with differently on configuration is if it's a 1542c/cf
which has the mbox-lockout 'feature'.

[9fans] Re: etherelnk3.c

[Nigel]

>But how do those controllers compare to the Qlogic board or
>the Adaptec 294x?
>
The Symbios (i.e. NCR as was) 8751SP controller out-performs the Adaptec
294x series.
Also, it has full on-board auto termination, allowing any two busses
(wide/narrow, internal/
external) to be connected without mucking around. Adaptec's major
attraction in the
marketplace has been the availability of ASPI drivers under Win95. This
has now been fixed for
Symbios as well (in OSR 2.1), to the extent that the Adaptec tools work
with the Symbios
controller.

As for availability of fileserver drivers, the Symbios/NCR driver on my
website

(http://www.cotswold.demon.co.uk/plan9/dist/ncr/src)

is #ifdef'ed for use as either a CPU or an FS driver. Indeed, it is used
by myself, forsyth, and
perhaps others (who knows) as a file server driver. I think forsyth used
a word like 'brisk'  or 'snappy'
to describe the performance. You can use any controller from an original
NCR810 right through to a
Symbios 875 without change.

As for an Adaptec 294x driver, I'm still working on it periodically. May
be even today.

[9fans] Re: etherelnk3.c

[G.David]

>>When PCI finally settles down and gets as reliable as 154x's on
>>the ISA bus, I'll move.  Of course a good SCSI adapter design
>>would be nice.  I hate the 294x.  Does anybody have any experience
>>with the Qlogic board?  (http://www.qlc.com)  It looks like
>>a good alternative.
>
>i know of drivers available for 3 other controllers:
>	buslogic (mylex)
>	dpt
>	ncr (symbios) 53c8xx series

Thanks for the info.

But how do those controllers compare to the Qlogic board or
the Adaptec 294x?  The QLogic board has two processors like
the 154x and you only get one interrupt per SCSI command.
(like the 174x. you can get many completed per interrupt on the
154x.) The 2940 gives interrupts as targets disconnect/reconnect!
The host processor has to almost manage the SCSI bus directly.
A 154x will even retry a command to a BUSY LUN for you without
issuing another interrupt.

On my systems I like to have as many SCSI busses as I can
so I can have a reasonable number of targets per bus.  So
having many cards that need to be patted on the butt every
time a target blinks is not good for getting any other
work done, like servicing ethernet clients.  I can put 4
154x's in a system with a P5/133 and have plenty of CPU
to keep the ethernet lit.  How many 2940's can you run with
a P5/133 with targets disconnecting/reconnecting like
crazy because of all the random I/O?

[9fans] Re: etherelnk3.c

[jim]

	>When PCI finally settles down and gets as reliable as 154x's on
	>the ISA bus, I'll move.  Of course a good SCSI adapter design
	>would be nice.  I hate the 294x.  Does anybody have any experience
	>with the Qlogic board?  (http://www.qlc.com)  It looks like
	>a good alternative.

i know of drivers available for 3 other controllers:
	buslogic (mylex)
	dpt
	ncr (symbios) 53c8xx series

[9fans] Re: etherelnk3.c

[G.David]

>>Of course the current support in the fs is for pretty slow
>>scsi controllers, from what I've seen.  One could stick a 
>>PCI controller that looks like an AHA1542 in there but the 
>>driver wouldn't utilize 32-bit addressing, forcing the use of
>>bounce buffers...  hmm, didn't some of the VLB cards have 
>>a larger address space?
>
>this has been gone over before on the list. given the buslogic eisa controller
>driver in the fs kernel (which is no slouch), it's trivial to make a buslogic pci
>controller work in 32-bit mode; that's what we use.

Well, a little work on the 154x, with multiple outstanding requests
per target, scatter/gather to 32k of queued operations, buson
time of 15 and busoff time of 0, is no slouch either; especially
with 4 controllers in a system with 4-6 targets each.  [This is
why I need a 3c515 busmaster ethernet card with 64k of RAM. :-)]

I also did a 1740x enhanced driver on the EISA bus to determine
how bad the ISA bus is.  I have the 154x on the ISA bus writing
a little less than 2MB/sec to the drives.  The 174x can do almost
4MB/sec.  (The 174x in standard mode also does about 4MB/sec,
bounce buffers notwithstanding.) I've seen a 294x (on *NIX) do
5MB/sec.  [Of course you really pay for it with the 2940.  During
that 5MB test 47% of a P5/133 was eaten up!  A test on the same
system with a 154x got 1MB/sec but used only 4% of the CPU.  The
154x is a very sweet design.]

In any case, random I/O cuts the rate per target to *much* less,
perhaps a couple hundred K/sec.  In this case allowing outstanding
commands, scatter/gather and disconnect make all the difference.

When PCI finally settles down and gets as reliable as 154x's on
the ISA bus, I'll move.  Of course a good SCSI adapter design
would be nice.  I hate the 294x.  Does anybody have any experience
with the Qlogic board?  (http://www.qlc.com)  It looks like
a good alternative.

One note, the code in the 154x driver says that the card does
not guarantee the order of SCSI operations which is why the
driver allows only one RBUFSIZE scsi command at a time.  This
is so true.  If you allow the SCSI subsystem to be more
asynchronous, expect the writes to be out of order and you
have to do something to keep a crash and running "check" from
eating your lunch.  Remember, fsck on *NIX only works if the
freelist and inode updates are well ordered.  Plan9 is not
any different.

David Butler
gdb@dbSystems.com

[9fans] Re: etherelnk3.c

[Eric]

> From gdb@dbSystems.com Mon Dec 29 17:36:38 1997
> Date: Mon, 29 Dec 1997 19:20:46 -0600
> From: eld@jewel.ucsd.edu (Eric Dorman)
 
> >Definately worth a look; I've got a 9pcfs that allows the use
> >of IDE disks for filesystems
> Why?  I agree IDE disks are very attractive from a $$/MB point
> of view, but you can't get enough of them on a machine.  The
> overall $$/MB is less with SCSI since you can aggregate the cost
> of the CPU/RAM over more disks.  Also, IDE is PIO and that
> is a bad place to waste CPU resources.

Well, one doesn't *have* to use PIO mode on IDEs, one can use
the supposed-DMA modes :)   Consider as well that it's unlikely 
that CPU is a premium in the fs; more likely it's bounded by 
network or disk bandwidth (offhand).  Besides, CPU is cheap on PCs,
and fs's aren't doing anything else.

With 8-9G EIDEs readily available, 32-36G is a goodly-sized 
magnetic level, and considerably cheaper than SCSI for the size 
range.  Around here SCSIs are ~2x-2.5x per G for ultrawide, and
1.5-2x for fast.  For the scope that I'm working in, 32G is 
fine for primary storage even.  Certainly the long-run cost 
amortization for SCSI is better, but that's only relevant
if it's going to be realized...

Of course the current support in the fs is for pretty slow
scsi controllers, from what I've seen.  One could stick a 
PCI controller that looks like an AHA1542 in there but the 
driver wouldn't utilize 32-bit addressing, forcing the use of
bounce buffers...  hmm, didn't some of the VLB cards have 
a larger address space?
  
> >                             and have found that the network
> >is far and away the limiting factor (10Mbit/sec 10BaseT on NE2000s)
> If you use two transmit buffers, sending one and filling the other,
> you will find much more "network" in your NE2000.  [I don't use
> the NE2000 anymore now that I have the 3c515 working! Not for the
> 100bT, but for the 64k of RAM and busmaster transfers!]

Well, whatever NE2000 mode being used in the cdrom for fs
is what I'm using.  I haven't dredged into it to see how it's
running the wire.

I don't recall offhand seeing 3C515 support in the code; is there
a boddle for it?

> >and 100BaseT is practically free these days; I'd love to use 100BaseT.
> Not when you look at the price/performance of 10bT full duplex switches
> and 100bT hubs.  100bT full duplex switches are nice, and expensive.

Sure, if you're building your own WAN network from the ground-up.  
We have much switched 10bT infrastructure already in place and some
switched 100bT sections (fiber backbone) so it doesn't cost me 
anything :) (at least at work) .. 100bT dumb hubs are plenty 
cheap ($50-70), fine for local runs and (hidden behind routers)
tightly-coupled fileservers and workstations.  

[xx] 
> >            Might even be able to interleave across primary and 
> >secondary IDEs (if the braindead chipsets will support it..). 
> No need, filsys main [h0h1] will interleave for you.

If h0 and h1 are on the same IDE controller you won't get
overlapping operations (unlike SCSI) since a single IDE 
controller can't do more than one thing at a time.  W/o 
overlapping the operations [h0h1] isin't a big win over 
(h0h1) (though better use of the on-disk caches is a help). 

On the other hand, lets say you have controllers h0 and h1, each 
with disks 0 and 1.  Then you can say [h0.0h1.0] and get two 
operations running at the same time (one on controller 0 and
another on controller 1).  The question, however, whether 
the chipsets will do it.

I suspect that the win from [h0.0h1.0] over [h0h1] will
be less than [h0h1] is over (h0h1) because of the on-disk
caches...

> >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. 
> Very possible.  I looked at doing a global long to ulong change
> but found some places that weren't easy to fix (I don't remeber
> where now), so I left it alone.  I was thinking of reducing the
> block size and needed more blocks.  If you leave the block size
> at 4K, and handle the multiplier like devwren does, then you
> shouldn't need to make that change.

Well, I found out what the problem was; stupidity on my part =:)
I forgot that the fs was basically multithreaded and ended up
reusing a buffer at the driver-level before the fs-level got
to it... ick.  Eliminated an intermediate copy too.  Now 
everything seems to work (for h0); big files, root fs, etc.
with ulong block addresses and file sizes.  Several builds 
and boots so far and no trouble.  It's off to h0.1 and h1.? 
land :)  I have to kick it in the butt with big files before
I'm happy with it though.

> >                                I chose the former as an
[h typecode in port/sub.c]
> >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.  
> Why?  Use different names.  
[xx]

What do you mean by 'use different names'?  Seems to me that if
port/sub.c references ideread/idewrite for type Devide
you'll have to have a ideread/idewrite stub in every set of 
architecture-specific drivers (not just pc) since you have
to satisfy that reference somewhere.  Unless, of course, you 
compile port/sub.c (with #ifdefs or something, more yuk) 
differently for, say, sparcs, than for pcs.  Am I missing something?

> >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.
> 
> Maybe.  I like the way it is now because my mirror code likes
> to know that a disk is missing (for whatever reason) and then
> know that it is available again later (a reboot cleared the error,
> or the drive was replaced.)  The config block is written to a
> mirror set with "config {w0.0w1.0}" and it tells you what the system
> is suppose to look like even if it doesn't look like that now.
> I have caused drive and controller failures and the system
> just takes the drive (or all the drives on a failed controller)
> off line and keeps running.  When the system is fixed and rebooted,
> it finds the mirrors needing recovery and does it.  Even if it
> is booted with the drives sick, it does the right thing.

Yeah;  If OTOH the table indexed controllers (which is the
real problem part anyway) rather than disks themselves, the 
only time the fs would have trouble is if it booted with a 
broken controller.  
 
> David Butler
> gdb@dbSystems.com

Regards,

Eric Dorman
edorman@ucsd.edu

[9fans] Re: etherelnk3.c

[G.David]

From: eld@jewel.ucsd.edu (Eric Dorman)

>Definately worth a look; I've got a 9pcfs that allows the use
>of IDE disks for filesystems

Why?  I agree IDE disks are very attractive from a $$/MB point
of view, but you can't get enough of them on a machine.  The
overall $$/MB is less with SCSI since you can aggregate the cost
of the CPU/RAM over more disks.  Also, IDE is PIO and that
is a bad place to waste CPU resources.

>                             and have found that the network
>is far and away the limiting factor (10Mbit/sec 10BaseT on NE2000s)

If you use two transmit buffers, sending one and filling the other,
you will find much more "network" in your NE2000.  [I don't use
the NE2000 anymore now that I have the 3c515 working! Not for the
100bT, but for the 64k of RAM and busmaster transfers!]

>and 100BaseT is practically free these days; I'd love to use 100BaseT.

Not when you look at the price/performance of 10bT full duplex switches
and 100bT hubs.  100bT full duplex switches are nice, and expensive.
(I'm looking at many nodes on the network, all *very* busy.)

If you follow the thread a while ago about the 3Com cards and the
big packet problem, you will see it's pretty easy to get the
3C509 PCI 10/100 card up and running (in PIO mode).  I still haven't
ported the Brazil driver because of the ongoing discussion about
ringbufs/blocks/msgbufs.  (I'm still leaning towards using the
ringbufs.)  But, once that is done, you'll have that option. 

>            Might even be able to interleave across primary and 
>secondary IDEs (if the braindead chipsets will support it..).

No need, filsys main [h0h1] will interleave for you.

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

Very possible.  I looked at doing a global long to ulong change
but found some places that weren't easy to fix (I don't remeber
where now), so I left it alone.  I was thinking of reducing the
block size and needed more blocks.  If you leave the block size
at 4K, and handle the multiplier like devwren does, then you
shouldn't need to make that change.

[snip]
>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 

What is the path set to?  Is it the first file or the second?
If it is the second, then you are overwriting 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 

Was it in memory correctly before being flushed?

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

Yes!

>                        or somehow patching into the scsi
>stuff below the Devwren level.

No!

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

Why?  Use different names.  You need to handle the translation
of RBUFSIZE blocks to real sectors somewhere.

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

Maybe.  I like the way it is now because my mirror code likes
to know that a disk is missing (for whatever reason) and then
know that it is available again later (a reboot cleared the error,
or the drive was replaced.)  The config block is written to a
mirror set with "config {w0.0w1.0}" and it tells you what the system
is suppose to look like even if it doesn't look like that now.
I have caused drive and controller failures and the system
just takes the drive (or all the drives on a failed controller)
off line and keeps running.  When the system is fixed and rebooted,
it finds the mirrors needing recovery and does it.  Even if it
is booted with the drives sick, it does the right thing.

When I added log support to the system, I thought about going
directly to scsiio so I could write less data to the log,
(you have to go down to that level before 512 byte blocks
are visible).  But I also wanted to use the striping [] and
mirror {} capabilities so I created another special file
system "log".  (Special in the way that "main" is special.)
This decision made many other things easier, e.g. I can use
the buffer cache for recovery (getbuf/putbuf) and bypass it
otherwise (devwrite).

I would recommend using what is there, it works pretty well.

David Butler
gdb@dbSystems.com

[9fans] Re: etherelnk3.c

[Eric]

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

[9fans] Re: etherelnk3.c

[jim]

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

------ forwarded message follows ------

>From cse.psu.edu!owner-9fans Mon Dec 15 13:30:30 EST 1997
Received: from cse.psu.edu ([130.203.3.50]) by plan9; Mon Dec 15 13:30:30 EST 1997
Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) with SMTP id NAA22716; Mon, 15 Dec 1997 13:29:56 -0500 (EST)
Received: by claven.cse.psu.edu (bulk_mailer v1.5); Mon, 15 Dec 1997 13:29:24 -0500
Received: (from majordom@localhost) by cse.psu.edu (8.8.7/8.7.3) id NAA22677 for 9fans-outgoing; Mon, 15 Dec 1997 13:29:19 -0500 (EST)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ns.dbSystems.com (root@ns.dbsystems.com [204.178.76.1]) by cse.psu.edu (8.8.7/8.7.3) with SMTP id NAA22673 for <9fans@cse.psu.edu>; Mon, 15 Dec 1997 13:29:13 -0500 (EST)
Received: (from gdb@localhost) by ns.dbSystems.com (8.6.11/8.6.9) id MAA16085 for 9fans@cse.psu.edu; Mon, 15 Dec 1997 12:14:33 -0600
Date: Mon, 15 Dec 1997 12:14:33 -0600
From: "G. David Butler" <dbSystems.com!gdb>
Message-Id: <199712151814.MAA16085@ns.dbSystems.com>
To: cse.psu.edu!9fans
Subject: Re: [9fans] Re: etherelnk3.c
Sender: cse.psu.edu!owner-9fans
Reply-To: cse.psu.edu!9fans
Precedence: bulk

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

[9fans] Re: etherelnk3.c

[G.David]

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

[9fans] Re: etherelnk3.c

[Eric]

> From: "G. David Butler" <gdb@dbSystems.com>
> To: 9fans@cse.psu.edu
> Subject: [9fans] Re: etherelnk3.c
> 
> Hello All!
> 
> I've just started the process of back porting the brazil
> etherelnk3 driver to Plan9.  I would like some feedback
> from this list (9fans) about some of the porting issues.
[xxx]
> After a quick perusal of the code, we have a big decision
> to make.  This brazil driver does not use RingBuf, it uses
> Blocks.  It also moves the Ctlr structure out of ether.h
> and into the driver .c file.  The former change allows
> more data to be buffered and the latter allows driver
> specific data to be localized.  These are both "good" things.

> Devether.c is not compatible with either of these changes,
> so we have to either update the entire ethernet subsystem to
> use Blocks, or make this driver use RingBufs and dirty the
> ether.h Card and Ctlr structures with the overhead of this
> driver.

  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.
 
> David Butler
> gdb@dbSystems.com

Regards,

Eric L. Dorman
University of California at San Diego
edorman@ucsd.edu

[9fans] Re: etherelnk3.c

[G.David]

I just got a correction from jmk@plan9.bell-labs.com:

>the list at the beginning of etherelnk3 is not meant to be
>a list of cards supported, just a convenient all-in-one-place
>list of product ids, they are spread around in the manuals.
>i.e. there's no microchannel support and i've never seen a
>t4 card.

[9fans] Re: etherelnk3.c

[G.David]

Hello All!

I've just started the process of back porting the brazil
etherelnk3 driver to Plan9.  I would like some feedback
from this list (9fans) about some of the porting issues.

The primary goal of this effort is to get the support of
the newer 3com cards into Plan9.  I don't want to change
the way it is used though.  In other words, you still use
ether0=type=3C509 in plan9.ini.  It professes to support:

/*
 * Etherlink III and Fast EtherLink adapters.
 * Product ID:
 *	9150 ISA	3C509[B]
 *	9050 ISA	3C509[B]-TP
 *	9450 ISA	3C509[B]-COMBO
 *	9550 ISA	3C509[B]-TPO
 *
 *	9350 EISA	3C579
 *	9250 EISA	3C579-TP
 *
 *	5920 EISA	3C592-[TP|COMBO|TPO]
 *	5970 EISA	3C597-TX	Fast Etherlink 10BASE-T/100BASE-TX
 *	5971 EISA	3C597-T4	Fast Etherlink 10BASE-T/100BASE-T4
 *	5972 EISA	3C597-MII	Fast Etherlink 10BASE-T/MII
 *
 *	5900 PCI	3C590-[TP|COMBO|TPO]
 *	5950 PCI	3C595-TX	Fast Etherlink Shared 10BASE-T/100BASE-TX
 *	5951 PCI	3C595-T4	Fast Etherlink Shared 10BASE-T/100BASE-T4
 *	5952 PCI	3C595-MII	Fast Etherlink 10BASE-T/MII
 *
 *	9000 PCI	3C900-TPO	Etherlink III XL PCI 10BASE-T
 *	9001 PCI	3C900-COMBO	Etherlink III XL PCI 10BASE-T/10BASE-2/AUI
 *	9050 PCI	3C905-TX	Fast Etherlink XL Shared 10BASE-T/100BASE-TX
 *	9051 PCI	3C905-T4	Fast Etherlink Shared 10BASE-T/100BASE-T4
 *
 *	9058 PCMCIA	3C589[B]-[TP|COMBO]
 *
 *	627C MCA	3C529
 *	627D MCA	3C529-TP
 */

After a quick perusal of the code, we have a big decision
to make.  This brazil driver does not use RingBuf, it uses
Blocks.  It also moves the Ctlr structure out of ether.h
and into the driver .c file.  The former change allows
more data to be buffered and the latter allows driver
specific data to be localized.  These are both "good" things.

Devether.c is not compatible with either of these changes,
so we have to either update the entire ethernet subsystem to
use Blocks, or make this driver use RingBufs and dirty the
ether.h Card and Ctlr structures with the overhead of this
driver.

To limit the scope of this effort I vote for changing this
driver to RingBufs and creating a structure in the driver
that I will hang off Ctlr.Card.dp8390 since that is not used
in the 3com stuff.  By doing this I will also provide the
changes I have done to support multiple ethernet cards.
This affects other parts of the system, but at least we will
get more functionality than we have now.

Since this effort is for the Plan9 community, I didn't want
remove functionality from this driver without a discussion.

If it is decided that we update the ethernet subsystem, perhaps
we can get Jim to provide further details to make future
backports easier :-)  In addition, we need someone to coordinate
the overall structure and own devether.c and ether.h.  Then
we need volunteers to work on all of the current drivers to
bring them into the fold.

Are we ready to build a team to do Plan9 enhancement/development?
We could use the FreeBSD model.  Or do we want to leave the
system as it is with Lucent as keeper of the updates?

Comments?

David Butler
gdb@dbSystems.com