/dev/dump

We've gotten a lot of good feedback from previous posting of the audiohd driver, and the Beijing engineering team has come up with a new version (Aug 12, 2008.) Note that the latest audiohd driver will always be posted here. One note: please use the obj32/ or obj64/ versions of the driver unless you are running a debug kernel. There are some binary dependencies where the debug drivers won't work on a production kernel.

Finally, after months of delay, the SDcard bits have been putback^Wpushed. This was interesting, because the SDcard bits were also some of the first bits to have been pushed into the new Mercurial tree -- and they're already in the clone. Adventurous people can start trying the code out now. Or just wait until b97. Of course, this also means that this will be a new feature in the OpenSolaris 2008.11 release. Yay! If you do try the bits out, let me know what works, and what doesn't. There seems to be some evidence from the Linux community that not all SDHCI compliant controllers are created equal, although the code I have works for the few variants that I've had access to. The bugster category for bugs is solaris/driver/sdcard

Finally got legal approval! A webrev is available, as well, in case anyone wants to look at it. I hope to have this integrated into b97.

The SDcard Phase I project is in the home stretch -- the only thing remaining at this point is two signatures. And one of those is my managers! (The other one is the final sign-off from legal, which I expect to happen tomorrow.) I'll file my RTI tomorrow evening, most likely. If folks, I can also post a public webrev at the same time (though that would just be informational, as the actual required code reviews have already taken place.)

Apparently Twitter has been hit by another Trojan , according to the BBC. What I love is the last paragraph in the article: Only those using Microsoft Windows are vulnerable to infection from these malicious programs. Of course, I only run Solaris at home, so I guess I have naught to fear. See, there is an upside to having a tiny market share on the desktop!

I still recall seeing the mail years ago , when the tools group told us that Teamware was EOL, and would not be supported any longer. I recall thinking, OMG, what are we going to do for ON? At the time, it looked (to me at least), like BitKeeper was a logical replacement. Now here we are, years later, and with the closure of build 96 last night, we have finally stopped using Teamware for new development at Sun. Mercurial/Cadmium seems like a powerful and capable replacement, and has the advantage of being open source. This is one of the most significant technical hurdles to fall that has kept external folks from being able to commit directly to Hg. (Opening up RTI, and the bug tracking database are the two remaining big ones. RTI can probably be opened without too much difficulty. The bug tracking problem is a different matter altogether.) As a nice side effect, external folks can now have their changesets integrated directly, without requiring sponsors to do conversion work, and

So, I got a message today, not uncommon, indicating that some poor guy is dealing with an IT organization that still requires link parameters to be forced to 100 Full. It hardly seems reasonable that in today's day and age, folks wouldn't be using auto-negotiated link parameters, yet, there it is! This blog entry is dedicated to those IT organizations stuck in the early 90's, still requiring their users to force link mode. 1. Back Story Once upon a time, 100 Mbps full duplex 100Base-T was new. And in the early days, there was not universal adoption of a standard (in the very early days there wasn't a standard at all!) for autonegotiation of link speed and mode. The IEEE 802.3 group (the folks that oversee the Ethernet standards) rectified this with a standard called "IEEE 802.3u", which provided the rules for auto-negotiation. Most of the world, and pretty much all of the equipment manufacturers, adopted this standard in short order, and there was much joy a

I recently upgraded to the "latest" OpenSolaris on my desktop. This is also my primary NIS and NFS server and boot server. I was rather dismayed at first by some of the bits that were missing. NIS, DHCP, and more. I finally got it all working, and I thought I'd document it here for posterity. First install NIS. "pkg install SUNWyp" (Configuration of NIS left as an "exercise" for the reader.) Second, DHCP was missing, so we install it as well: "pkg install SUNWdhcs SUNWdhcsb SUNWdhcm" (Configuration of DHCP left as an exercise...) Then, it turns out that there was no manifest for TFTPD, not even a commented out entry in /etc/services. I copied the line from /etc/inetd.conf on another system: tftp dgram udp6 wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot Then run "inetconv". My question to the OpenSolaris/Indiana folks -- why wasn't this listed in the stock inetd.conf -- even as a commented out entry? W

Some of you may have been wondering about the work I've done for SDcard. Well, it looks like we have basic agreement at this point, and I am only waiting for the lawyers to draft the final text granting the approval, and then I'll be able to supply the bits publicly, as well as integrate them into OpenSolaris. I'm expecting that this could happen as soon as build 97. Stay tuned, and sorry for the delay. (Internal folks can access bfu archives for Intel based system at /net/zcube.west/export/ws/sdcard/hg-x86/archives or for Tadpole SPARCLE /net/zcube.west/export/ws/sdcard/hg-sparc/archives. There's an internal webrev up as well at http://jurassic.sfbay/~gd78059/sdcard/ -- enjoy!)

A few weeks ago, I committed changes to start the clean up of a bunch of lint overrides in the kernel, and provided text explaining how to continue the work (along with admonishments to do so.) I am very happy to report that it seems that some folks took what I said to heart, and over the past couple of weeks there have been a continual stream of lint related fixes, such as this one . Thanks to everyone who's helping out!