Hello.  Since I've last written on this topic, I've made significant
progress on this front--not quite enough to merrit a bug report, but very
close to enough, and as soon as I can get my hands on some additional
hardware, I hope to have some patches for folks to try.  
	In the end, I decided to stick with the wm(4) driver, because, as Bill
noted, I found it was smaller, and, ingeneral, it seems to work well with
the actual handling of data once things are up and going.
	What I did discover, though, is that for  fiber-based cards, autonegotiation
is completely broken at the moment--we don't seem to flip the right bits on
the chip to even get that process started.  Worse, if you  try to disable
autonegotiation by using a nailed up media string on the ifconfig command
line, the driver still tries to tell the chip to use autonegotiation.  Finally,
for chips newer than the 82543, our driver can't detect when there's a
signal present on the fiber itself.
	What I've done so far is add patches to properly detect the presence
of optical signal, and to allow you to bring up a link without
autonegotiation.  These patches work fine, modulo some confusion on my part
with dual port cards.  What I'm going to try to do is fix that confusion,
so that you can force links up without autonegotiation, and, time
permitting, figure out how  to get autonegotiation to work on the tbi
fiber-based interfaces.  I believe that all the copper stuff is fine.
	Finally, I have a question. Do folks think it worthwhile to try and
tie the wm(4) driver to the gentby(4) phy driver for fiber based cards?
Right now, the wm(4) driver rolls its own phy driver for the fiber cards,
and I assume there was a reason for this, since Jason wrote both the
gentbi(4) driver and the wm(4) driver, so he must have been aware of the
gentbi(4) presence.

-thanks
-Brian