Off to Brisbane, Austrialia

I'm headed to Brisbane for the week -- I'm presenting at Kernel Conference Australia 2009. I hope to meet other like minded UNIX kernel nerds there. Maybe do some snorkeling as well, although its the off-season there. (But it can hardly be colder than the water in California...)

STREAMS and non-STREAMS in the same driver

Some of you kernel hackers may be interested to know about my case (PSARC 2009/380) that eliminates one of the ancient limitations of Solaris -- having STREAMS and non-STREAMS entry points in the same device driver. I've also implemented it and am waiting for the case to time out before I submit the RTI.

As part of this, I also implemented a set of changes to the audio stack -- the austr(7D) "speecial" node and driver goes away, and the Sun audio personality sheds about 1,000 lines of complexity. I'll be pushing those changes later, once I've gotten code review feedback. (If you review the changes, please let me know!)

mii related fallout

So there was some fallout from my mii push. Elxl devices had a nasty panic, which I fixed in time for build 119. Some older i82557 (iprb) devices had problems as well. The push for this fix went into build 120. To everyone affected, please accept my apologies. Build 120 should be stable for these devices.

Common MII/GMII layer integrated

Folks working with 802.3 (Ethernet) hardware (10/100/1000) can rejoice, as I've now integrated PSARC 2009/319, which provides a common MII and GMII layer for Ethernet device drivers. The first batch of drivers (iprb, dmfe, and afe) have been converted. This brings support for SunVTS netlbtest, dladm based link management, and even (for some devices) 802.3 flow control (aka Pause Frames) to these drivers.

I'll encourage folks working with other drivers to update their drivers to support the new framework. On average it cuts about 1500 lines from most drivers, and generally improves device functionality.

And yes, it works with Ethernet, even 1000Base-X should work (although only 1000Base-T has been tested.)

Any device that supports Clause 22 of 802.3 should work. Clause 45 (typically 10Gb) is not supported, however.

audiovia97 webrev posted

I've posted the webrev for audiovia97. This was covered by PSARC 2009/321. This is a driver for older Via 82C686 south bridges, used with 32-bit Via C3 and Pentium-III class processors.

The driver was written by 4Front (apparently building upon other Boomer work I've done). All I've done for this is simple packaging, cstyle fixes, and integration.

Let me know if you want early access to binaries! (You'll need Boomer or build 115 or later installed to use it.)

audiocmi integrated

I just pushed the audiocmi driver. Users with C-Media 8738, 8768, and 8338 devices can now enjoy Boomer using 16-bit stereo audio on these devices.

Note that while some of these devices can support multichannel surround, the Solaris driver for them does not support this kind of usage at present. If someone in the open source community would like to contribute support for this, please let me know.

proposal to change policy of SPARC deliverables

Historically, subsystems (drivers, etc.) were supposed to deliver on both SPARC and x86 platforms (and now amd64 as well) unless a really good argument was supplied. While I've long been a supporter of this philosophy, I think a time is coming to consider making a specific policy exception.

The problem I'm running into is with legacy PCI devices. Some of these legacy PCI devices can work SPARC. But devices that don't support 66 MHz frequently (but not always) have problems on SPARC workstations. The biggest problem is that many SPARC workstations have 32-bit 33 MHz slots that don't supply 3.3V. This affects quite a number of cards that require 3.3V power to operate. Some devices will operate with only 5V, but only marginally. I've seen a number of failures that I think can be traced to this problem, and now I don't recommend using PCI devices not specifically qualified for these platforms with SPARC systems. (Sun makes that same recommendation, btw.)

Furthermore, identifying suitable SPARC hardware can be a challenge. SPARC systems these days are slower than their x86 counterparts, yet for the most part remain more expensive, and there are few inexpensive options available for open source developers. And, SPARC desktop systems are effectively off the market -- Sun doesn't have any current SPARC desktop models for sale, and that's not likely to change anytime soon.

So what I'd like to propose is a policy change that recommends authors working on drivers for legacy PCI cards be given a blanket waiver for SPARC delivery. (Examples are recent NIC drivers such as "vr", "sfe", and "bfe", and audio hardware such as "audiopci", "audiocmi", and perhaps in the future drivers for Creative Audigy cards.)

I still believe that developers working with modern PCIe devices should deliver both SPARC and x86 binaries though. PCIe is available on last generation SPARC desktop (Ultra 25/45) hardware as well as current generation server products.