/dev/dump

I just committed a change to move 7 previously closed drivers in Nevada to the open source tree under usr/src. This change involved nothing more than Makefile and copyright block editing, so it was pretty much a no-brainer. (Though the heavy lifting of the legal review had already been done.) The drivers moved were: bscv, bscbus, i2bsc, gptwo_cpu, gptwocfg, todstarcat, and todm5819p_rmc. Admittedly, none of these are likely to exist on your hardware, but it does help to have more bits open. Hopefully someday /usr/closed will either cease to exist or become its own consolidation separate from Nevada.

Hmm... it looks like I never posted the webrev... well here it is, the webrev for the eri(7d) conversion to Nemo . Now, the second bit of good news here is that the PSARC case for this as been submitted as PSARC 2007/243 . Note that the case isn't published publicly at the time of writing, but it should be soon.

FYI, the afe and dmfe cases I had at PSARC (2007/229 and 2007/221 respectively) were approved. I've already put back the dmfe code. The afe code will be committed by Alan DuBoff. I've got pre-approval to do a follow-up putback to convert afe to GLDv3 afterwards. Note that as a result of Crossbow, there are some changes coming in GLDv3, so it is still inappropriate to use GLDv3 for unbundled drivers. (The biggest of these changes is support for "polling", where the network stack can disable interrupts on the NIC and run a separate thread to poll the device for inbound packets. On extremely high traffic systems, this can have a big impact on overall system throughput by avoiding the extra context switches.)

The PSARC fasttrack to integrate afe into Nevada was assigned case number PSARC 2007/229 . Notably, this case was not submitted by me (I'm not even on the interest list!), and is being done as a result of the BSD license terms for afe. It will probably be reviewed at next week's PSARC meeting.

Finally, over 20 years since the late Jon Postel said Death To IEN-116 , we have finally removed it from OpenSolaris. Who says changes in Solaris take too long?

As predicted, the area of biggest risk in my conversion of eri to GLDv3 was in fact the kstat handling. However, I appear to have that all worked out now, and the binary is working flawlessly on my SunBlade 100. Even suspend/resume works fine. However, I've not yet integrated this code properly into a workspace to generate a webrev, but I will do so soon. (Probably tomorrow... I'd like to get my two other RTIs put back first.) One of the biggest concerns about this effort was the added risk that doing this conversion might bring to the "stable" eri driver. So, I'm asking the community for help. If you want to help out with testing, especially if you have higher end systems or want to do some benchmark comparisons, please let me know. (I don't have specific test suites to give out that this time... its of more value frankly to have people using their own tests right now, that way we get broader test coverage than perhaps we might with a single test suite....

I've just finished (still testing!) my port of eri to GLDv3. Between that and eri, and looking at existing GLDv3 drivers (bge, rge, e1000g), I think I have gathered some operational experience that I hope we can use to improve Nemo. (So, anyone who says my time spent on converting eri was wasted is wrong... because if nothing else it gained some more operational experience with GLDv3.) Executive summary of the takeaways I have gotten so far, that I think are worth noting: There is still a lot of code duplicated across even GLDv3 drivers (more below) Lock management is so much simplified GLDv3 kstats need "work" we really, really need Brussels ... it can't come soon enough. some drivers can probably be changed internally to work even better with GLDv3 than a naive port So here's the detailed stuff. code duplication The duplicated code falls into three major areas. ioctls (mostly ndd (1M) and loopback handling for SunVTS), kstats, and MII. For now I want to f...

In case you ever wondered what it takes to convert a "simple" GLDv2 driver to Nemo, have a look at the webrev I posted earlier today. I'm hoping that this work will get integrated soon. As an upshot, dmfe with this change "just works" with dladm show-dev.

I'm now a member of the "battery team". I had a very productive con-call with the folks involved, and I think we are going to soon have a better common framework for battery APIs in the kernel so that SPARC systems can also take advantage of the gnome battery applet. Watch this space!

For the curious, I've posted a webrev containing the changes required to integrate afe into Nevada. The driver includes changes from the stock AFE driver for Solaris, including some lint fixes, and changes to use the stock Solaris sys/miireg.h. I'd love to make more changes to this driver, but at the moment I don't want to cause a test reset. Once the driver is integrated, I have a bunch more improvements coming... Nemo, multiple mac address support, VLAN support, link notification support (needed for NWAM), as well as code reduction by using some features that are now part of stock Solaris (like the common MII framework!)

Core support for SPARCLE was just putback! I'm getting ready to post an initial tadpmu for public review soon, as well. This should make you SPARCLE/Sun Ultra 3 owners out there happy.

Recently, I posted a blog entry where I described that " Not All GigE Are Equal ", strongly advocating the use of Broadcom GigE devices when faced with a choice. However, after spending time in the code, I've discovered that there is quite a range of differences amongst Broadcom gigE devices. I had considered listing a full table of them, but it seems that would be a bit onerous. Take a look at usr/src/uts/common/io/bge/bge_chip2.c if you want to find out the gory details. But in the mean time, here are my recommendations: If you have PCI or PCI-X: Choose a bcm5704 if you can. It has pretty much full feature support, but you need to pick a recent revision (newer than A0.) Look for pci ids of pci14e4,1646, pci14e4,16a8, or pci14e4,1649. These chips alls support PCI-X, multiple rings, full checksum offload, and multiple hardware tx and rx rings. If you have PCIe: As far as I can tell, all of the PCIe chips that are Solaris supported lack support for multiple hardware ...

As part of setting up the Tadpole project, I tried to use a feed direct from Blogger , but the OpenSolaris tonic infrastructure doesn't like it. Apparently the feed has some problems, which you can see by looking at the output from feedvalidator . Anyway, I was able to work around by using feedburner to convert the blogger Atom feed into a clean RSS feed . Maybe at some point some Blogger staff will look at this and see what the problem is.

Gman (Glynn) made a hackergotchi from a photo I sent him, which is used on planet.opensolaris.org . His gimp-fu is great. Thanks Gman!

The Tadpole project is now live!

The first review for Tadpole platform support is online now. Please let me know your thoughts, after reading it. There will be more good stuff coming soon, I hope. (Also, if you have a Tadpole platform other than a SPARCLE or UltraBook IIi , and are willing to test, please let me know!) Thanks!

I just received two e-mails (identical to each other) stating this: Dear DAmore Garrett, The Heritage Registry of Who's Who is recognizing you for possible inclusion in the upcoming 2007-08 Edition. Please go to http://theheritageregistryofwhoswho.com and click on the invitation button. Thank You, Chris Jespersen I'm not entirely convinced this is a worthwhile thing... but I'm willing to play along until they ask me for money. Anyone else out there received these before?

FYI, I recently proposed a new project to track improvements to support for Tadpole platforms in OpenSolaris. It looks like it got the seconds needed, so I'm just waiting for the infrastructure to be created.

I just made my first putback to ON (6487387 pcic driver contains obsolete & private Tadpole code that should be removed). While this is nothing earth shattering, hopefully I'll be making a lot more commits soon.

I've been wondering how many other OpenSolaris users there are out there in the Inland Empire. I recently met one close to me, which surprised me quite a bit. I figured I was the only one within at least a 30 mile radius. If there are others of you out there, please drop me a line. I'd like to inquire as to whether it makes sense to consider starting a User's Group for the area. Possibly we could join up with any other User Groups for Southern California. For the record I live in southwest Riverside county, not far from Temecula and Murrieta. (For those of you not familiar with the west coast, the Inland Empire refers to a large region of southern California that is separated from the coastal areas of Orange and Los Angeles counties by a range of coastal mountains. I often have joked that I'm about 65 miles from any natural technology center, but now I'm not so sure. And I think a lot of people who commute to places like San Diego and LA live out here.)

Funny note. When I came back to Sun (two weeks ago), I discovered that an ancient PSARC case (2002/356) for the removal of the Trivial Name Server (in.tnamed) had never been completed. So for 5-odd years since we've continued to ship this long-since-obsolete protocol. I'm going to go ahead and drive forward with the actual removal... at the time I did it as a case study in how much process was involved with even a simple EOF. Lets see how long this one takes. (For the record, the IEN-116 protocol was obsolete as far back as 1986, when J. Postel first requested vendors ditch it.)

Those of you using afe (and also mxfe) will be pleased to note that the time is fast approaching when afe will hopefully be integrated into Solaris Nevada. There is a PSARC fasttrack scheduled for it next week if I understand correctly. (I don't have the case number yet.) There are a few ramifications of this. One of the most immediate is that I'm going to be winding down support for versions of Solaris earlier than 10. In fact, I no longer have any personal installations running anything less than S10u3, and most everything is running Nevada. The other reason for me to do this is so that I can immediately start taking advantage of some features that are present in Solaris 10 and Nevada. For example, I want to add support for DLPI link notification, and ultimately (in Nevada) port to GLDv3 . The GLDv3 has some compelling features, and as a result afe and mxfe will gain support for features like vlans, jumbo frames, and interrupt blanking. And, they'll also benefit fr...