Showing posts from December, 2009

Shortest Audio Driver?

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 pos

Do you use IDN? (E10K inter-domain networking)

I was looking, and one of the legacy device drivers we still support is the Enterprise 10000 Inter-Domain Network. This is a memory based interconnect network that emulates an ethernet. It occurs to me that we could update this driver to use the GLDv3, which would potentially have a significant performance boost for it. (Really, a better solution would be to create a new low level MAC type for it Nemo, but clearly that's probably too much pain for a product that is no longer shipping). Anyway, I'd be interested to hear of any sites which use IDN on E10K class systems, and would like to see this (already high performance) network get another boost. The other legacy SPARC drivers which are not GLDv3 compliant are: cassini (ce) (probably never going to be GLDv3, but that's another matter) gem (ge) -- this one could be easily converted *if* I had fiber cards to test it with, although there are political concerns as well. (It uses the same MAC controller as "eri&qu

New audioctl coming soon

I integrated a replacement for mixerctl (and also removed mixerctl) back in build 130. Well, build 130 is coming out really soon (I believe it is available internally in SXCE form now.) I think therefore that it is time to provide more detail here about the new audioctl syntax: NAME audioctl - audio mixer control command line application SYNOPSIS audioctl list-devices audioctl show-device [-v] [-d device ] audioctl show-control [-v] [-d device] [control ...] audioctl set-control [-v] [-d device] control value audioctl save-controls [-d device] [-f] file audioctl load-controls [-d device] file DESCRIPTION The audioctl command is used to control various features of the audio mixer and to get information about the audio mixer and the audio device. The audioctl command operates on the following data types: device An audio device, such as "audiohd#0". The subcommands that accept this do so as an argument to an op

quick system identification

I am frequently needing to know "which system am I using". (I have trouble keeping track of which ones are which) -- i.e. is this the laptop, the Ultra 20, the whitebox, etc. I had been using smbios a lot, but that's a bit awkward and non-portable to SPARC or systems that don't support smbios. Here's a quick script that can quickly tell me what model I'm working on. It works on SPARC and x86 alike. I have it stored in ~/bin/system -- it only works on Solaris of course. Feel free to borrow, reuse, whatever -- I hereby donate it to the public domain: #!/usr/bin/ksh sysconf=`/usr/sbin/prtdiag | head -1` biosconf=`/usr/sbin/prtdiag | head -2 | tail -1` sysconf=${sysconf#*:} biosconf=${biosconf#*:} sysconf=`echo ${sysconf} | /usr/bin/sed -e 's/^ //g'` biosconf=`echo ${biosconf} | /usr/bin/sed -e 's/^ //g'` if [ -z "$sysconf" ] then printf "BIOS: %s\n" "$biosconf" else printf "%s\n" "$sysc

new aquarium lights

Some of you may know that I keep a salt water reef aquarium (210 gallon). Well, one of the challenges with such aquariums is lighting -- most corals need a large amount of high quality light to grow. Most systems use metal halide lighting, which is extremely bright, and extremely hot. On my aquarium I've used three 250 watt MH lights, supplemented by a pair of 150 watt MH lights. (The 150s have been out for a while due to a bad ballast.) Yes, that's over a kilowatt in lighting. And MH lights have historically been considered some of the most efficient lighting -- i.e. most lumens or PAR per watt. One alternative that has been up and coming has been LED based lighting. High power LED systems offer a lot of potential capabilities (although due to a patent problem that has put at least one company out of business and probably set the industry back at least five years, software based control of LEDs is only available on extremely expensive lighting systems -- systems costi