/dev/dump

Boomer, aka PSARC 2008/318 -- the new audio subsystem for Solaris, and the project I've been working on for the last several months -- has released source code for our work in progress. A status update and link to the webrev is available here.

Earlier today I just pushed a fix for suspend/resume when the machine has a floppy disk drive. Surprisingly, a lot of modern machines still have floppy disk drives in them, and this fix enables those platforms to participate in the S3 suspend work. The fix will be in b105. One such machine is the Dell Precision M390. I imagine there are many other desktop class systems of this nature. While suspend/resume has been focused largely on laptops (where battery life is a paramount concern), I suspect that enabling suspend-to-RAM for desktop class systems will ultimately have a larger environmental impact, since it is those systems that typically consume the most power. So, perhaps this small change will have a somewhat significant impact. If you have a platform that this enabled suspend/resume to work on, tell me about it. Include smbios output in your message, too. :-)

I've heard a number of problems with folks trying to use SDcard with Ricoh controllers (such as found on certain newer Toshiba Tecra laptops), as well as lack of quiesce(9e) support, and various other problems. To address these problems, I've made a bunch of changes, and am looking for code reviewers and testers -- the webrev is an open review. I've made binaries available to anyone who wants to try these out. To try out the new binaries, just untar the sdcard-20081202.tar.gz file in your / directory. You might need to reboot for them to take effect. (If you know how to modunload the drivers from kernel memory, that will work too, provided that you don't have any SDcard media inserted at the time.) Please let me know any feedback you might have. Thanks.

It seems that I often run into the same problems over and over again, and I see many device drivers which often suffer from the same problem. Here are some strategies I use in my own coding -- maybe someone else will find them useful. To my knowledge they have not been documented elsewhere. KISS. Start with as few locks as you need to get the job done. Only add locks when performance analysis shows you need them. I usually start with an assumption that I'll need one lock per device instance, and possibly a single global lock. (If you don't have global state, you can elide the global lock.) For some kinds of drivers (NICs in particular) I introduce a lock for each major traffic direction (so one lock for rx, and one for tx) per instance. Global state is evil. Global state requires global locks. Global locks often introduce lock ordering problems, and can also more likely to be contended in systems with lots of devices. Thou shalt not sleep in STREAMs entry put (9E) and

Bryan Cantrill has just posted one of the more excellent blog posts I've seen this year -- he manages to put to words some of my heretofore unvoiced doubts about transactional memory. I'm a big fan of KISS, and both TM and multilevel threading seem to fail on that front.

In another update, I've updated fdc (the floppy disk controller) so that it supports suspend/resume even if a floppy drive is present. There is one caveat though -- namely that the drive must be empty. Still, its far easier to pull a disk out of a drive (if you even have one -- most floppy drives these days probably see very little, if any, use), than to disconnect the drive entirely. You can download the file from the device drivers download page (look for a file named fdc-2008-11-01.tar.gz). A webrev of the changes is also posted. For the curious, the reason for the above caveat is best stated by the following explanation extracted from a comment in the code: Bad, bad, bad things will happen if someone changes the disk in the drive while it is mounted and the system is suspended. We have no way to detect that. (Undetected filesystem corruption. Its akin to changing the boot disk while the system is suspended. Don't do it!) So we refuse to suspend if there is media p

I've updated iprb ( Intel Pro/100 Ethernet driver) to support suspend/resume and quiesce (fast reboot). I've also made some other changes, such as updating to the latest microcode from Intel, fixing some potential races, and improving the internal implementation of the statistics routine. I'd like folks to try it out on their Intel or AMD platforms. The tarball can be downloaded from here (look for iprb-2008-11-01.tar.gz). I still want to get this open sourced, but I haven't got approval from the lawyers yet. But here are the binary bits in case anyone is waiting for them. (I'm not planning on porting this driver to SPARC. There are too many places in the code that would have to be changed to use endian-safe calls to ddi_get, and I think there is probably very little demand for a SPARC version of the driver. If you are one of the people who do want SPARC support for iprb , please let me know. Enjoy!

I've posted draft inception materials for our PSARC case, 2008/318, for Boomer. Boomer is the code name for the effort to integrate a modern OSS-compatible API, and additional drivers, into Solaris. PSARC inception review for this case is scheduled for November 5, 2008. Please check the ARC web page for call in details (any engineer in the community may dial in.) Be advised that the meeting is an engineering meeting, though. (PSARC provides engineering architectural review for projects.) We have a working prototype for most of the bits we are ARC'ing at this point, and I expect to be opening up the source code tree, and binary test bits, in the coming weeks. Perhaps by Thanksgiving.

A new position in Austin, TX has opened in my group (onsite only). This is for a junior or mid-level administrator or QA type person -- great for someone who loves playing with new hardware, software, etc. No specific programming skills beyond every day scripting required (though perl and C would probably be useful.) Send replies back to me. (Full disclosure: I get a referral bonus for anyone I refer.)

Some folks might be interested in this. I used to hack on NetBSD at my previous job. I recently had an inquiry from a recruiter at Microsoft (don't worry Neal, I'm not going anywhere! :-) which I thought I'd share here. Location : Redmond, WA Client: Microsoft. Job Description: Seeking a talented NetBSD software developer interested in helping Danger (a subsidiary of Microsoft ) ship the next generation of Danger’s Sidekick platform. Specifically, we’re looking for NetBSD developers interested in commercializing the NetBSD platform for an embedded mobile computing device, focusing on performance and optimization, bug fixing, and integration with Danger’s higher-level platform code, with an emphasis on kernel and driver support. Qualifications: - 8+ years of software development experience - 8+ years experience with C - Strong understanding of OS concepts (particularly with NetBSD) such as multi-threaded program design and synchr

OpenSolaris 2008.11 is coming soon. Build 101 is the stabilization build before it, and as usual, new features are excluded from this build. So we can say pretty certainly what features are in, and what are out. While there are a lot of new features coming in this release, there are some in particular that I've been more involved with. SDcard support. Numerous laptops can now use SDcard and MultiMediaCard media directly. A good way to know if you're laptop is one of them is to search for pciclass,0805 in the output of prtconf -vp . While it isn't completely conclusive (in particular some models from Texas Instruments are schizophrenic here), if you see this, there's an excellent chance it will work. I'd always like to hear feedback about this feature -- if your unit works, or doesn't work, let me know. (Also, of course, the Tadpole SPARCLE models are supported. ) AudioHD improvements. Notably, many more laptops will now have working audio. The a

Okay, maybe not so ancient (circa 2000), but I recently got an e-mail from the Sun IT group notifying me about changes that impacted web pages I set up for Alternate Pathing, which was the very first project I did that involved work within the Solaris kernel. Apparently they didn't notice that I'd left the company and returned. Of course Alternate Pathing was canceled a long time ago, although someone may still be using it on older E10K Solaris 8 systems. Here's the Sun internal URL to which the e-mail referred. The bug tracking pages are broken, since the scripts behind them were developed (by me) to talk to the BugTraq+ Sybase server, which Sun hasn't used in ~forever.

This weekend, the code for the IOMMU for Solaris on Intel ( PSARC 2008/560 ) was pushed . This has potentially profound ramifications for folks working on Solaris device drivers, and I thought I'd take some time to talk about them. First off, it needs to be noted that we've had an IOMMU on Solaris SPARC pretty much for as long as we've had Solaris on SPARC. (In fact, most SPARC platforms have to use an IOMMU -- they have no choice.) But on x86 this technology is new. The benefits that IOMMU brings are many fold. It virtually guarantees that all DMA requests can be set up with a single DMA cookie, reducing complexity and eliminating the use of bounce buffers by the DMA framework -- even for old devices with unfortunate restrictions (such as an inability to perform dual address cycles on PCI -- i.e. no 64-bit support.) Such restrictions are actually fairly common place. It allows for strong isolation to be given for devices that can be accessed via other virtual machines

The latest & greatest audiohd driver, which includes vastly improved support for a large number of codecs, suspend/resume support, and a generic "codec parser" has now been "pushed" into build 98 of ON. Many thanks to the Beijing audio team, who worked long and hard to bring this project to fruition.

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!

I recently started communicating with some family via "texting", because, for reasons I don't fully understand, they will happily respond to a text message (and send them out on their own), but won't answer a regular phone. So ignoring the annoyance of trying to draft up a message on the toy 10 key keypad on my phone -- which takes approximately 20 times as long as it would to say the same thing in a voice call, I started thinking about the economics behind the texting fad. My provider charges me $0.20 per text message. My overlimit minutes cost about $0.25. (Picture messages cost more -- $1.95 each, I think.) This is the biggest swindle made by phone companies in recent history. Look at the data involved. A phone call (voice message) takes the following bit of bandwidth: Assume 8-bit ULAW or ALAW sampling (12 bits compressed to 8 bits) Assume 8 kHz sampling, which is typical for "phone quality" audio That gives up 8 * 8000 = 64,000 bits per second or 3,84

I've just posted the latest experimental version of the OpenSolaris audiohd driver. This driver includes the latest work from the engineers in Beijing, including a widget parser that enables the driver to work on a much larger variety of audio configurations. As most motherboards these days ship with an audiohd compliant device, this should greatly expand the support for audio on Solaris systems. The above driver binary also includes suspend/resume support. Note that this is not the anticipated Open Sound System driver, but rather an extension of the pre-existing Sun driver. It won't work with OSS. However, there is some chance (I've not tested it myself) that this will even work on Solaris 10. A webrev of the changes should be posted soon. In the meantime, if you want to give this a whirl, let me know the results. (To test it, just copy the binary objects into /kernel/drv/amd64/ or /kernel/drv and reboot. -- Yes there are ways to do this without a reboot, but the cav

This may be interesting to some people -- and its recorded here for posterity. A number of NIC drivers in Solaris have been developed using "copy-paste" approaches. As a result, there are a couple of family "lines" for NIC drivers. le (ancient 10 Mbit only) driver, is the common root for one heritage. From le was developed hme. From hme were developed qfe, eri, and gem. From these was developed ce. And ultimately, from these was developed nxge (although nxge shares little with its ancestors anymore.) Another heritage goes back to ancient dnet (tulip) drivers on x86. dnet begat dmfe, which begat bge. There are probably other drivers that bge spawned, but its hard to know for sure how much copying may have occurred. afe and mxfe were developed pretty much independently from the others, although afe was developed first, and begat mxfe (which is for very similar hardware -- a good counter example for a case where copying the code made sense -- of course I'm

A common approach to device driver design is to start with a device driver for a similar piece of hardware that someone else wrote, and copy it, then modify it. However, this approach is fraught with peril, and I thought it might be a good idea to record my thoughts on this for posterity. If this post saves just one future developer from falling into this pit, it will have been worthwhile. The first problem is that most device drivers have a number of non-trivial "features" in them that relate to the specific issues of a particular piece of hardware. Often this means that there are internal design features of the driver that are not ideal for a new driver. (A classic example would be nxge's use of particular hacks relating to the location of it in relation to the IOMMU on certain Niagra processors. No other driver is ever going to need that.) The second problem is that most device drivers are not 100% bug free. The copy-modify approach to coding tends to lead to bug

Starting with build 93, OpenSolaris will no longer have support for the ISA based SoundBlaster Pro, SoundBlaster 16, and SoundBlaster AWE32 devices. This shouldn't impact anyone, although its possible that bochs or qemu users may be impacted. (I've not heard of any such users successfully able to use the sbpro driver in a Solaris guest environment though.) In the future, we may look into adding support for emulated ESS 1370 devices. In the meantime, VirtualBox emulates an Intel ICH based AC'97 support, which works with the audio810 driver.

Its possible that is just showing up for me, but recently the "toolbar" at the top of my blog has become unusuable. Instead of a normal set of links, I just get a row of repeated Blogger icons. I'm using firefox 2.0.0.7 on Solaris Nevada. Anyone else seen this?

I'm interested in collecting data about audio devices that folks are using. So, I've a few questions, which maybe folks could send answers to me. Here are the questions: Is there already support in Solaris for your audio devices/needs? (If yes, stop here, and no need to send me any information -- you're already covered as a "mainstream" user.) If you're using 4Front's OSS, and you're using a hardware driver other than apci97 , hdaudio , ich , via8233 , atiaudio , then please let me know what driver you are using, and what the actual audio hardware is ( cat /dev/sndstat might be useful here.) (If the audio is built into a motherboard, I'd like to know the make/model of computer, and the rough date -- year -- that you purchased it.) Do you use/would you use hardware MIDI support? Are you using digital audio (Dolby Digital/AC3, and/or SPDIF) on your Solaris system? If so, please provide detail. Do you have any use for more than a single active

It seems to be a recurring theme, but we keep hearing about different WLAN parts that don't work with NDIS wrapper, or other problems building the NDIS wrapper etc. I've never used the NDIS wrapper, and I refuse to do so. I also refuse to purchase or recommend any laptop with a Broadcom WLAN part on it, at least until Broadcom changes their position and makes it possible for 3rd parties (even under NDA) to develop device drivers for their WLAN products. The reason is simple: until laptop manufacturers start losing sales due to people who take the same position, they won't stop including Broadcom WLAN on their products. The loss of a few individual WLAN cards won't impact Broadcom at all, but if Gateway or Dell stops purchasing WLAN parts, then its a whole new ballgame. And the more laptop vendors that we can get to understand that use of Broadcom leads to lost sales, the more impact it will have. Either Broadcom will take notice, and correct their behavior (e.g. by

Its been a busy week. In the past week, there have been three separate putbacks: 1) Kerry Shut putback a fix for audiohd to suspend/resume 2) Brian Xu putback a fix for iwk to suspend/resume 3) Judy Chen putback a fix for ath to suspend/resume The upshot of this is, if you have a laptop with an Nvidia graphics card, its a fair chance that your laptop will support suspend (and resume!) A big thanks to everyone who's been working on this.

I've just putback the changes to afe and mxfe to rip out the driver-private ndd support code and replace it with much cleaner and simpler mc_setprop(), mc_getprop() property access functions supplied by Brussels. For common link parameters Brussels does the NDD compatibility support for us. Yay! Drivers can be smaller. There's a couple of opportunities here for folks to contribute driver improvements: 1) convert existing NIC drivers to the newer framework. E.g. rge, dmfe, maybe others.... (hme and eri for sure, but they may be hard due to the plethora of driver private properties they support via ndd). 2) try hard to remove private driver ioctl() support in favor of Brussels property functions 3) ADMtek centaur parts can support flow control, on certain hardware (pretty much anything shipped in the past 5-7 years.) Adding support for this in afe might be a relatively simple project, especially for someone familiar with ethernet flow control. Contact me if you want to work

So, since some folks may be wondering what I'm up to, I thought I'd briefly mention it here. I've been asked to serve as tech. lead on the project integrate the software from 4Front's Open Sound System into OpenSolaris. Surprisingly, this task isn't quite as straight-forward as it might seem. There are a number of outstanding issues that have to be resolved before the project can integrate, and we're working frantically to get them all resolved. We've also staffed up the project enough to increase the man power significantly beyond what was associated with in the past. So we are looking to drive this project to successful conclusion soon. I'll have news about this in the future -- watch this space. But I will say this much -- it looks like in the not-distant-future there will be the ability to use OSS APIs from userland applications on *all* Solaris systems. This includes systems with older chips not supported by 4Front today, and Sun Ray thin clien

For those of you who've been wondering what happened to the SDcard work... The technical work finished quite a while ago. However, due to some vague language in the disclaimers associated with the SDcard simplified specifications, Sun has decided it is best if we are a member and have a full license to the SDcard specifications (although only the simplified specs were used in its development.) Of course, this got the lawyers involved in reviewing license agreements and membership agreements, and purchasing machinery engaged, since there is now a transfer of funds involved. (The funds transfers have already been approved.) The very last hurdle to having this stuff in OpenSolaris is clearing the hurdles with the legal group (and the latest is some concern about trademark rules associated with the SDcard org.) Once we get those final hurdles cleared, hopefully I'll be able to putback the code. And yes, its all Open Source -- CDDL. Watch for in build 90 (hopefully). (The rule t

This week (Tuesday and Wednesday) my father took my 8-year old daughter to Joshua Tree National Park to do some rock climbing. She'd done some simpler climbing before, briefly, a few years ago, and had enjoyed it. (Of course, she did awesome, and everyone around seemed quite impressed by her awesome instincts. Watching her route-find, and use hand holds and moves with flexibility that I can only dream about being able to do was very, very cool.) The added bonus here was that I was invited to go along as well -- I had never been rock climbing before, and I was anxious to try it myself. (Dad's been climbing for about two years now, and talking about it pretty much continuously since -- now I think I know why.) It was awesome ! First off Joshua Tree National Park is absolutely amazing... and it's only about 90 minutes away by car from where I live -- I can't believe I've been missing out on this. (Even if you don't rock climb, there are some beautiful hikes,

The results of the OpenSolaris 2008 ballot are in -- congratulations to the members-elect. It looks like a solid group of folks, and I am encouraged for the new year! (On a side node, I'd like to have seen a bit more representation from non-Sun employees, but the elected members are all folks I believe have a high level of integrity, and will serve the community's interests well.)

I just recorded my vote in OpenSolaris. If you're a Core Contributor, please go to poll.opensolaris.org for instructions to register your vote! For the curious, I voted FOR the two amendments, and my priority list is for a public bug system, public RTI system, SPARC build farm, x64 build farm, and to clean up inactive CGs. I am not reporting my OGB selections, other than to say that it included a mix of candidates from Sun and non-Sun candidates, and included some former OGB/CAB members, and some fresh faces.

Owners of laptops with Intel 4965 802.11n hardware will be glad to know, iwk has returned. Hopefully, all the legal confusion is sorted out properly this time, so it should be here to stay. For very small technical changes, there was a lot of work involved to make this happen, and a big thank-you to everyone who got it done, and to the community who've been patient with us while we made sure we were Doing The Right Thing. Now I just need to get one of my own.

Well at least I'm not the only one in my household. But it can be really fun. The past week has been a great example of this. For our 4th anniversary last month, my wife and I bought a 56 gallon freshwater setup. At the time we had a 10 gallon setup and 2.5 gallon that we were using to house babies from our livebearers. (Platy/swordtail hybrids, I think.) That was about 3 weeks ago. Today, we have a 46 gallon bow front, a 20 gallon, and another 10 gallon. Plus the 56 gallon and original 10 gallon tank. (Now both my of my daughters have their own 10g freshwater setup, the wife has the 46 g for her community ... mostly she wants a home for more more mollies and a peacock eel, but also probably some angels and a few red-eye tetras.) The pet store had a sale. We uhm, went a little crazy. (A complete 20G freshwater setup was only $40.) The 56 gallon display tank (24" tall) got converted to saltwater. This is my first marine tank. I only got it filled up last night. (And

This post discusses the 2nd flag-day putback yesterday, which is Brussels (phase I). Brussels also changes the way NIC drivers are administered, but it is focused on simplifying and centralizing the administration of network driver tunables -- these are the values used to tune the device itself, or in some cases, the link layer properties. The most common of these tunables are the values associated with duplex and link speed settings. Historically these values have been configured with ndd (1M) or driver.conf (4). Many people know how I feel about those methods, but let me just reiterate: "ndd must die!" (And driver.conf, as well.) The Brussels putback represents another opportunity for community members interested in kernel programming though. A lot of these NIC drivers need to be converted to use the property access methods that Brussels offers, and have the ndd support ioctls removed. (And yes, I strongly desire to see the ndd(1M) ioctl support removed from drivers.

Folks watching Nevada putbacks will have noticed at least 3 flag days in the past 24 hours. I want to take a second to talk about the first of them. (I'll talk about the second in a follow up post.) The first, Clearview/UV, is about providing GLDv3-like features to legacy NIC drivers, and about providing friendlier names to device drivers. I will confess that I've not had a chance to play with any of these features yet, but I think that they are likely to be one of the more important putbacks to OpenSolaris this year. This putback fundamentally changes network administration by offering the ability to use "logical naming" for network device drivers. The other important thing here is that some folks may believe that the Nemo Unification offered by Clearview/UV means that those legacy drivers don't need to be converted. This is not true. Conversion to GLDv3 still offers significant and tangible benefits to network device drivers: Performance. The translation

My former Internet service provider, OChosting , was recently purchased by a much larger company, Velocity Networks . As part of that acquisition, they moved my e-mail to some more central server. However, they screwed it up really really badly. The DNS MX records for my domain pointed to an old server, but the CNAME I was using for IMAP was pointing to the old one. The helpdesk was completely useless/powerless to fix the DNS records. (As part of this they were transitioning the old systems to a new management system, ala CPanel, as well. The helpdesk people were only able to deal with accounts that had been transitioned. Finally I told them they'd not only lose my business, but I'd post my negative experiences here if they didn't get someone to help me quickly. That much they did. But ultimately, the promise that DNS records would clear up when caches flushed never materialized. Two weeks later their servers are still giving out incorrect DNS information. I've