Friday, June 12, 2009

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

Tuesday, June 9, 2009

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.

Saturday, June 6, 2009

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.

driver private headers

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:

  1. 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.)
  2. The header file is not delivered to customers (except as part of the entire source code), shrinking the amount of disk space consumed on development workstations.
  3. No exceptions entry is required to suppress the file from delivery - so the file is referenced in fewer places. (Fewer places to change if the file needs to move, be removed, etc.)
  4. The header file is easier for humans to locate with the source.
  5. The header file is faster for the compiler to locate -- it will be in the first directory searched - slightly faster build times. (If enough subsystems do this, it might start to make a noticeable improvement.)
  6. The common include directory becomes slightly more manageable with each such change. (Big directories with hundreds of files are awkward.)
  7. The file can't be used/abused by other subsystems (at least not without making such abuse obvious), because it really is in a private directory.

The upshot of all this is that a bunch of driver-private header files have been slowly moving out of uts/common/sys/ and into better locations. Hopefully other driver developers will consider doing the same.

Friday, June 5, 2009

driver.conf files considered evil

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 for everyone or nearly everyone, or using another system like Brussels to provide configuration overrides.)

(PCI devices in particular are very painful to configure with driver.conf... see the pci man page to find out why!)