Post a Comment On: /dev/dump

Using my new framework changes (which have not integrated yet), along with changes in the framework designed to simplify drivers by providing certain ordering guarantees, I've been able to shrink a lot of the audio drivers (and in the process have also found a number of small bugs that I think ultimately were responsible for jitter and corruption). Ths simplest driver so far -- audiovia97, which is about as simple an AC'97 driver that can be, is only 686 lines. Several others are now less than 800 lines, and no longer need any locking primitives. As far as device drivers go, this is minuscule. In fact, I challenge anyone to identify a driver that fully services any "real" piece of hardware, fully supporting said hardware, in fewer lines of space.

(And in case you are wondering, a significant fraction of those 686 lines of audiovia97 is still comments and whitespace and even the 30+ lines of boilerplate -- the driver is written to be as readable as reasonably possible, at least to other device driver or kernel engineers.)

The forthcoming audio DDI will be about the easiest DDI for any kind of device driver in Solaris. Contrast that with the pre-Boomer SADA framework, which one could argue had the most cumbersome and painful DDI for non-nexus devices.

Hopefully the simpler framework will make it easier for others to provide new drivers, and result in far fewer "bugs" in the drivers. (And of course, the smaller drivers will result in more efficient use of kernel memory as well, although you are unlikely to notice that particular difference.)

(However, the complexity of the audiohd driver remains a serious thorn in our side -- and unfortunately the problem is made worse by a far-too-complex specification for the Intel HD audio system That said, the complexity in audiohd stems largely from offering too many codec configuration choices, and not from the part of the driver responsible for actually transporting audio data.)