/dev/dump

I undertook this past weekend an effort to "port" the NetBSD "ex" driver to GLDv3, as an open source replacement for "elxl". It took a bit over 2 days. The new sources are on line in a webrev format. I'd really appreciate feedback. I'm hoping to integrate these changes soon (and I could use help with testing!) This new version, apart from being Open Source, also has with it: 1. Full support for VLANs (including full-MTU frames) 2. Full support for link notification on twisted pair (and hopefully also fiber) 3. Full integration with Brussels for MII and media selection. 4. Full support for Suspend/Resume (S3) 5. Full support for Quiesce (fast reboot) 6. Support for additional devices It can also be extended fairly easily to support Cardbus and MiniPCI variants, and hardware checksum offload. (The checksum offload part is basically written and #ifdef'd out until I find a newer card to test with personally.) What is missing is "automatic...

Happy New Year (2010) everyone! I thought I'd take a second to reflect on the accomplishments of the past year, and look forward to what I think is in store for my contributions to OpenSolaris this year. It's hard to believe that I've been a member of the OpenSolaris community for over 5 years now. (I was a pilot member.) Undoubtedly this past year my biggest contribution to OpenSolaris was the new audio framework ( Boomer ) and many new audio drivers. I did a lot of other work besides, including a bunch of work on NIC drivers (including a new common MII framework and the yge driver which supports Marvell Yukon 2 parts), and various changes to the SDcard framework. I've also developed a device driver for a very interesting (and very high performance) hybrid storage device (which won't be integrating for non-technical reasons), and a new storage framework for block oriented storage devices. (This framework, blkdev , will be integrating once we're out past...

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

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",...

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 option -d. ...

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" "$sysconf...

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