hme gldv3 status report

The conversion of hme to gldv3 looks like it is a success. The driver "Just Worked" from the first time I loaded it. Yay.

Still to be tested are the main areas of risk: VLANs, SUSPEND/RESUME, and DDI detach. Stay tuned for more on that front.

I'm going to have to preserve qfe as a seperate driver, I think, because renaming/renumbering devices is just going to cause too much grief in the field. But, what I'm going to do is make hme.c and qfe.c very small (say ~50 lines each), and have them use a common misc module to provide the entire functionality.

I have now received several qfe boards as well, so I'll be testing on x86 soon, as well.

Watch this space for the code review to be posted.

For the curious, some size comparisions:

gd78059@sr1-umpk-52{8}> wc pcic/usr/src/uts/sun/io/hme.c{,.orig}
6498 19423 171291 pcic/usr/src/uts/sun/io/hme.c
8889 26403 232421 pcic/usr/src/uts/sun/io/hme.c.orig
15387 45826 403712 total

size in the kernel (as reported by modinfo): old = 63384, new 47184

Comments

jamesd_wi said…
When can we expect to see integration into Nevada? I would love to try out this code on my ultra 2.
Unknown said…
Well, I'm trying to clean up some things first, and I need to test DR and suspend resume. (A lot of the clean up is making this driver work, and work well, on x86. There were some ugly code paths in the DMA flow in hme. I'm cleaning all that code up.)

Anyway, I'll probably post a web and binaries up in the next week or so. Integration into Nevada itself is unclear, because of the "official" QA test burden.

Popular posts from this blog

An important milestone

SP (nanomsg) in Pure Go

GNU grep - A Cautionary Tale About GPLv3