/dev/dump

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.

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.)

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.

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.) Fur

Some may have noticed in a few of my changes lately that I'm moving some header files around. This post explains the change (and encourages others to do the same). Header files that are only useful to one subsystem (a kernel module, or driver, for example) should, IMO, only be located in the subsystem for which they are used. For example, do we really need to ship a header file in /usr/include/sys/ that has all the register definitions for the DEC tulip ethernet (dnet.h)? Wouldn't it be sufficient to have those definitions just where they belong, alongside the source for the dnet driver itself? Locating the files for such subsystems in their own directory instead of a common directory (e.g. common/io/dnet/dnet.h instead of common/sys/dnet.h) has several positive ramifications: It makes it readily apparent that the header file has no content needed outside of the kernel or subsystem. So changes can be more freely made (no userland dependencies, for example.) The header file

Just a quick note on driver.conf files that some device drivers deliver. I believe that driver.conf files, and the tunables that are usually put in them, are for the most part, a byproduct of inadequate architecture The average driver should use no tunables in driver.conf properties. As a result, I've started going out of my way to remove driver.conf files from device drivers for which I'm responsible. I think that even the "advanced" tunables (such as the interrupt rate used for audio drivers) falls outside the scope of what users should normally tune, and that delivering a configuration file is actively harmful. One of Solaris' great strengths historically has been the approach to "self-tuning", so that lots of configuration is not necessary. I'd like to see that continue. The next time you think about adding a driver.conf property, consider carefully if there might not be a better solution. (Either self tuning, providing a default that works