Showing posts from June, 2007

GLDv3 iprb putback

I just putback the GLDv3 conversion of iprb. It will be in the next SXDE/SXCE. (b69 and later). It is still closed source, but I think that may change soon, too. (All the technical information in the code is reproduced on a public open-source developers guide downloadable at Intel, with the exception of the binary microcode, which is in the FreeBSD tree under an Intel-owned BSD license.) Anyway, I'm told Sun is having a meeting with Intel, and one of the agenda items is opening the source to iprb. Meanwhile, enjoy the GLDv3 goodness.

afe GLDv3-ified

I've converted "afe" to GLDv3 in anticipation of it getting putback. I've also greatly simplified the buffering logic in it, because I was trying to be "too clever" and I think we were seeing failures during the extreme testing that Sun QA likes to perform. Anyway, this means that when afe gets putback (its on a schedule for snv68, but that may or may not happen), it will be GLDv3. Yay. Here's something to whet your appetite: garrett@doc{44}> pfexec dladm show-link eri0 type: non-vlan mtu: 1500 device: eri0 afe0 type: non-vlan mtu: 1500 device: afe0 This was done on a Sun Blade 100. No more legacy nics! This is also helpful for laptop owners, because afe is one of the more common cardbus devices. So, your cardbus 10/100 NIC will work with NWAM. If folks running snv_66 or newer want test binaries, let me know. I can offer them up in exchange for beer.

mxfe code reviewers sought

I'm also looking for folks to review my mxfe driver. It is posted at Thanks!

hme code reviewers sought

I need to get code review coverage over the hme GLDv3 conversion. This is also a good chance to learn what it takes to convert a legacy DLPI driver to GLDv3. If you can help out, please look at the code at The sooner I can get quality code review and test coverage, the sooner we can put this back! :-)

The Need For Public Test Suites

Now that OpenSolaris is supposed to be "Open", the community needs a way to perform quality assurance tests so that community contributions do not block on Sun QA. Currently, putback of changes to code to Solaris requires QA validation. For example, in order to putback my updated iprb and hme drivers (or my new mxfe driver), I have to get QA coverage. This means that I also have to get the time of someone from Sun, which can be challenging. In order to free the community from Sun's grip, we have to have alternatives, so that community members can perform testing; giving the necessary quality assurance needed for (Open)Solaris, without blocking progress. Hopefully someday soon the efforts of the folks who own the test suites to open them up will address this problem. For now, we just have to wait...

On life, the Universe, and everything...

Well, maybe not so much the Universe, as our own galaxy.... I recently came across a statement that there was an estimated 100 billion stars in our galaxy. I started to wonder, about the odds of us encountering sentient life in the galaxy, so I started running some rough calculations, just to estimate. Astronomers estimate that approximately three out of four stars may harbor planets. (Basically, any unary system, plus any binary system where the companions orbit at least as far from one another as Pluto orbits our own star.) Again, these are rough estimates. So, maybe 75 billion planetary systems exist in our own galaxy! For the moment, lets call the probability of a planetary system harboring a planet capable of supporting life is p . Lets call the probability of life developing on such a planet l. Lets call the probably of sentient life developing from more primitive forms (at any point, without regard to the time it takes) s. Further, lets assume that the average age of a

eri GLDv3 and nemo fixes putback

In build 67, you'll find that eri(7D) is now a Nemo driver, with full support for IP instances, VLANs, trunking, etc. As a consequence, you may have to fix scripts that do ndd /dev/eri since they now need to use /dev/eri0. Nemo driver developers: you no longer need to syslog link status changes. In fact, please don't, because Nemo does it for you now. Next up, hme, and (surprise!) iprb. (iprb was done last night on a bet.. Steve owes me a beer.)

Is GLDv3/nemo conversion of legacy drivers worthwhile

That very question, specifically with regard to hme and qfe, but also some others, has come up lately. I'm of one mind (I think my position is clear by the very fact that I've invested effort here), but not everyone shares my opinion. In order to have an on-line concrete resource I can point internal Sun naysayers at, I'm asking you to voice your thoughts here, by posting a follow up to this blog. (Sorry, no anonymous posts, but that means your posts will carry all that much more weight.) Do you still use hme/qfe in systems? What about Sun Trunking with qfe? Would you upgrade to Nevada if there was GLDv3 support for these NICs? Would Nemo features in qfe/hme help you? Would a port of hme/qfe to x86 be useful to you? Please post a follow up on my blog here, with your opinions!

more network driver updates

I just completed my codereviews of eri, and got approval from the owners of the code to commit the changes. I expect that as a result the eri conversion to GLDv3 (plus major cleanups in the code) will be putback next week ... probably on Wednesday afternoon. Why Wednesday? Well, I also need to commit PSARC 2007/298 and 2007/296, which the eri driver depends on. 2007/298 was the source of much debate lately, but I think a consensus has been achieved, and the changes should go in once I get the final blessing from PSARC (which at this point is pretty much a foregone conclusion.) Code reviews and testing have already been done. I've also sent an mxfe card to Alan DuBoff, so he can run it through the NICDRV battery of tests. Hopefully as a result mxfe will be integrated soon. I'm anxious for Alan to commit afe (he has asked that I not take this over from him), so that I can quickly convert it to GLDv3 as well. For some of the other legacy NICs (iprb, rtls, etc.) I've been