hme shrinks by about 40%

I just removed about 40% of the code from "hme", by converting it to use the common MII layer. It also makes it use Brussels, and fixes an old bug relating to 10 Mbps functionality. Another net negative lines of code integration for me. I wonder if this confuses ohloh.net's accounting?

OpenSolaris on snv_124 Impressions

I've bitten the bullet, and finally installed "OpenSolaris" over my SXCE install, upgrading from build 105 to build 124 in the process. I thought I'd share some things I've noticed:

• Gnome's volume control Just Works, and doesn't show the legacy Sun device anymore. (Yay!)
• There is a 12 MB Core file on the CD ... er... too big... DVD ... image. (Oops!) Maybe someone was hoping the community would jointly debug the program that generated the core file. (gtk-update-icon).
• Still no /bin/tcsh installed by default. Fortunately easy to get off the network for this machine. (For other systems, not so easy. This really ought to be fixed.)
• AudioHD has a really, really annoying beep on this system. The beep volume control doesn't take effect until you lower it to 33%. (And then it gets really quiet.) This is a bug that I'll have to investigate further, there's probably some codec tweaking needed.
  
• Regular SunOS vi has been replaced with vim, which has an incredibly obnoxious bug. It doesn't scroll down properly, redrawing on the last line in the terminal window instead of the whole screen. This is IMO at least a P2 bug against the editor. The old editor in SXCE, while maybe lacking some neat colorization features and not being open source, at least worked properly.
  
• Trying to install CUPS using the package manager GUI fails with a horrible stack back trace. While the request is is made to report the problem with the stack back trace, there is no provision to save it or e-mail it. So alas, I don't have it anymore to post. It should be easily reproducible. (It looked like a problem relating to the SMF configuration.)

I have a lot more to do... so many things are at the moment still missing. But I think I'll be able to muddle on at this point. (The vim bug is going to really, really bug me though, because there isn't an easy workaround -- apart from just copying over the old vi from SXCE.)

Update: Turns out /usr/xpg4/bin/vi (which is what I had in my path anyway) doesn't have this problem. And its installed by default. Yay. But someone really needs to fix vim, because that bug is horrible.

Update 2: When I logged in using my old home dir, the Gnome panel which I had configured for auto_hide did hide itself. But unfortunately would not unhide itself with any mouse actions. The only way I could get it to unhide was to disable the auto_hide property using gconftool2. Unfortunately, it took a while to figure out how to use this.

Giving up on laptop-discuss@

Here's a message I sent to laptop-discuss-owner at opensolaris.org:

Okay, I've tried *three* different addresses to post to laptop-discuss@... each time the message bounces.

The addresses I tried:

gdamore@sun.com
garrett.damore@sun.com
garrett@damore.org

I give up. The list is *unusable* to community members, because of a draconian list policy that instead of just moderating reasonable attempts to post to the list just *bounces* them. This community (laptop-discuss@) will no longer be able to receive mail from me, despite the fact that I'm probably one of the more active contributors to the software that makes up core laptop platform support.

If you think your membership ought to be able to hear from me, then please make it easier for me (and for other people) who have a legitimate need to post to the list. Simple moderation with white and blacklisting can be used to achieve this.

- Garrett

For the record, the message I tried to post was:

I'm considering a case to remove/EOF the partial (incomplete) support we have for certain Tadpole laptops in Nevada.

I'd like feedback on this. Is anyone out there still using a Tadpole SPARCLE with OpenSolaris or Solaris Nevada?

The reason for this is the intention to remove support for graphics (its already not present in OpenSolaris). I never got enough cycles to finish the work to integrate power management or other mobility features for this platform (SPARCLE), and now it seems to be quite obsolete. We're talking about UltraSPARC-II (up to 650 MHz max cpu speed) systems here.

Would anyone here strongly object to just removing the support?

- Garrett

The bounce messages I received look like this:

You are not allowed to post to this mailing list, and your message has
been automatically rejected.  If you think that your messages are
being rejected in error, contact the mailing list owner at
laptop-discuss-owner@opensolaris.org.

The problem is that draconian list membership/posting rules make posting updates incredibly painful. If you think my contributions to the forum are or would be useful, please ask the list moderator to start actually moderating the list instead of just setting it on auto-reject. (At this point, I don't remember which vanity address I subscribed to the list using... at the moment, I'm just about to the point of not caring. I've already reached this point with driver-discuss@ - on more than one occasion I've simply decided not to keep trying to send a message to that alias because of the same stupid draconian policy.

why we might never support Dolby Digital

SPDIF (and AC3) are the (now legacy) ways that home theater systems are supposed to use to transfer high end surround sound to the receiver for amplification and distribution to individual speakers.

Many audio cards on the market can transport AC3 (aka Dolby Digital) or DTS compressed audio data over a digital cable (SPDIF). They can also transport 16-bit stereo PCM (uncompressed) to SPDIF.

Boomer can't decode or encode, or transcode, any compressed audio at the moment. While it might be nice if we could do this, there are significant and non-trivial hurdles to making that happen. Some are technical (such as computational costs and lack of hardware offload), and others are more legal (such as trademark, licensing, and patent considerations.)

So, Boomer could transport uncompressed 16-bit stereo over SPDIF. (That's all SPDIF has bandwidth for!) Which we support today in audiohd. And in the future we might extend this to other devices.

However some operating systems also support a pass-thru for compressed audio data, where data is taken from a source (such as a DVD application) and routed directly to the receiver without any changes. This works reasonably well, except that it adds a lot of complexity to make it work right, and you completely lose any control over gains or the ability to mix other audio sounds with the stream. (Want to get a notification of an incoming VoIP call while you are watching your movie? Too bad... you can't do that with AC3 passthru.) This mode is of such limited use that we're inclined not to support it at all -- its really only useful for media center PCs used in conjunction with home theater systems to watch DVDs. (And we already know about the various problems with watching commercial DVDs right? I won't talk about those legal problems here.)

The best feature for SPDIF is the ability to transfer 6 streams of data in a single cable -- using a lossy compression. The reduction in cables to tie this into your home theater system is really a good thing. But of course, we don't have an encoder, so we can't do that except in the pass-thru case we already said we weren't going to do. (So no 5.1 gaming via SPDIF for you... Dolby calls this Dolby Digital and all audio cards that support it do so in software only, which requires expensive licenses from Dolby.)

Fortunately, there are better options on the horizon, and this is where we want to spend our time.

One option is ADAT ("lightpipe") -- which can support 8 channels of uncompressed audio at 48 kHz. Its available on some motherboards even now. Supporting it would probably be fairly easy, although using ADAT might require some very high end audio equipment (ADAT is used in professional audio situations.)

A second, and far more accessible option, is the use of HDMI's audio channel. New motherboards (and some cards, such as the Asus Xonar HDAV) can support HDMI audio. HDMI supports 8 channels of uncompressed audio at up to 192 kHz. This is plenty for even the most demanding audiophile. And if you want more channels, you can always use a second HDMI cable! HDMI offers us the best audio capabilities without any compromises. (We can use it with mixing, volume controls, or use it in a bit-perfect fashion. We get full quality. And we don't have to deal with any of the licensing, technical, or legal headaches that accompany trying to get a real-time AC3 or DTS encoder working. ) So at this point, any investment spent in AC3 instead of HDMI on our part just looks kind of silly.

I expect that sometime later this year (or more likely next year), we will be looking hard at getting HDMI audio working with Boomer. (Note that I have no control over funding or project priorities -- so this is just a prediction, not a promise.)

audio driver enhancements

Okay, I've got some audio drivers that are basically ready to go, but which I'm trying to decide whether to integrate or not. Part of the problem is that integration of new drivers is a somewhat expensive process, and if there is no demand for some some of these, then I'd rather go do other things.

So, another straw poll. If you have one of these devices and you want a driver to test with, please let me know.

1. Cirrus-Logic/Crystal CS 4281 -- driver is ready to go, stereo only
2. FM-801 -- I think the driver will work, but don't have hardware at the moment to prove it.
3. C-Media 8738/8768 surround sound support (stereo already supported in OpenSolaris) -- this will probably be integrated at some point, but I can share binaries now if someone wants them.

Other drivers I can supply with just a modicum of effort, if there is demand:

1. Yamaha YMF-7 series -- driver not yet ready, but now I have hardware to work on it, if there is demand
2. C-Media 8788 - driver mostly ready, but no hardware, and its expensive hardware to purchase.

Note that I will be doing the driver for the oft-requested EMU10K (Audigy/SB Live!) devices very very soon. Don't bother asking me again about it; its pretty high on my priority list. Likewise, X-Fi is very very desired, but will probably be quite a while longer in coming due to lack of specs. Various VIA chips (Envy24HT, etc.) are in the pipe as well.

And of course, Sun Ray audio is very high priority. Stay tuned for more on that.

ohloh.net statistics

I notice that OpenSolaris has very few "users" listed on ohloh.net. Lets bump it up. If you use OpenSolaris, why not go ahead and create an account on ohloh.net, and indicate "I use this" for OpenSolaris.

While you're there, if you're grateful, you could grant kudos to your favorite developers. And if you have any contributions of your own (pushes to ON), go ahead and claim those to (search for your name or login in the "people")... it bumps your rank, and makes your "kudos" worth more when you deign to give them out.

ESS Solo-1 (audiosolo) integrated

I just integrated audiosolo -- it should be in build 125. :-) I think this driver might have set a new record for integration into ON. I started work on it Sunday afternoon, and integrated into ON on Tuesday evening. Proof that not all integrations into ON have to take forever. (Granted if this were NetBSD it probably would have integrated on Monday morning instead of tonight...)

Crazy Sunday -- ESS Solo-1

I got kind of bored on Sunday afternoon, and decided to do a port from FreeBSD of the driver for the ESS Solo-1 card. (I got one of these cards shipped to me by mistake from a vendor that didn't know the difference between different chips.)

It was getting late on Sunday, but I was almost ready to test. I resolved that when the system panic()'d, I'd call it a night and go get some sleep.

Amazingly, the system never panic()'d. I think this is the first time that I've brought up a new device driver (with a lot of new code!) without crashing the system at least once. (Usually its significantly more than that!) Hence, this may be the only device driver I know of that is both functional, and has never been the cause of a system crash.

Well, I wound up continuing to hack during testing -- never did make it to bed, and now its pretty much done. I'll post test binaries if someone else wants them. I still have to test suspend/resume and quiesce. There is also a bug where the record channels are swapped. This stumped me for several hours until I finally realized that my channel remapping facility in Boomer isn't supported for input channels, only for output (playback). Guess I'll have to go back and add that feature in to Boomer. (Its a small change, and now I've got a need for it.)

The driver is called "audiosolo", and will only be supported for x86 systems (the hardware can't address past the upper 24-bits of memory, so its useless on SPARC). Its only capable of 16-bit stereo record and playback, but these cards are apparently still sold as very low-cost budget add-in boards. (They are also found on some systems.) Look for ES1938 on the chip.

If you want the driver, let me know and I'll ship out some binaries. It will probably go into the next build or so, as I have time to get through the C-Team paperwork. I'm not meant to be working this during the "day job", as I have other priorities at present. But it might be a nice bonus for someone anyway. :-)

NWAM and MII toxicity in build 123

Just a quick note.... we've discovered a problem where NWAM may not function if you have certain devices which use the "mii" module in build 123 of OpenSolaris. Hopefully the fix for this problem will be integrated today into build 124.

The problem is that NWAM won't see your wired "interfaces" as down, and as a result, won't default to using wireless.

Affected devices are afe, iprb, atge, dmfe and the yge beta test. The CR on this is CR 6880492. A webrev of the fix is available for the curious.

audiop16x driver integrated

From the HEADS UP message:

The push of CR 6878663 (PSARC 2009/384) introduces support for audio for certain Creative Sound Blaster Live! devices. If you have such a device, you can now enjoy audio playback and record support using your audio device. This driver includes 5.1 surround sound support.

Devices supported are identifiable by the PCI id pci1102,6, and are Sound Blaster Live! models SB0200 and SB0213. They have a chip labeled "EMU10K1X" (note the "X") on them. These were primarily marketed as Dell OEM versions of the Sound Blaster Live! family.

Enjoy!

audiols integrated

I've integrated the audiols driver into build 124 (actually I think this might have been the first push into snv124 -- thanks to jmcp for approving it so quickly!) From my HEADS UP message:

The push of CR 6875005 introduces support for audio for Creative Audigy LS devices. If you have such a device, you can now enjoy audio playback and record support using your audio device.

Devices supported are identifiable by the PCI id pci1102,7. Known compatible devices include Creative Audigy LS, Creative Audigy SE, Creative Sound Blaster Live! 24-bit, and Creative X-Fi Extreme Audio.

This driver includes 5.1 surround sound support.

Bugs for this driver should be filed in bugster using solaris/audio/driver-audiols.

Assorted audio cards needed

4Front has provided some drivers for me, which are nearly complete, but which need some attention. However, I am lacking hardware for a number of these drivers, and have not had good success finding many of them on eBay. If you have access to spare cards to donate, or even sell, please let me know.

Here's a short list of cards:

1. CS4281 (I tried to purchase one of these, but they shipped me an ESS Solo-1 instead!)
2. CS4280
   
3. FM-801 (ideally a 6-channel variant)
4. CMI 8768
5. CMI 8738 (6-channel, or even 8-channel varient)
6. CMI 8788 (these are high end cards, they can be purchased, but right now I'd have to fund this myself if I want to work on the driver -- its not a priority. This is typically the Asus Xonar card.)

There are probably other interesting audio cards as well.

It should be said that the recent work on some of these cards is occurring on my own time, since I have higher priorities (not soundcard related) during my day job, which is why its hard for me to ask Sun to provide funding for these things. (In the case of cs4281 and fm-801 cards, I've found them hard to even locate. Witness my failed attempt to purchase a CS4281. Taiwanese vendors consider these interchangeable parts. :-(

audiols works nicely on sparc

Just for giggles, I went ahead and tested it:

audiols/fortyfive> pfexec audiotest -5 /dev/dsp1
Sound subsystem and version: SunOS Audio 4.0 (0x00040003)
Platform: SunOS 5.11 snv_119 sun4u

*** Scanning sound adapter #2 ***
/dev/sound/audiols:0dsp (audio engine 1): audiols#0
  - Performing audio playback test...
    <left> ................OK
    <right> ...............OK
    <stereo> ..............OK
    <left rear> ...........OK
    <right rear> ..........OK
    <center> ..............OK
    <lfe> .................SKIPPED
    <5.0 surround> ........OK
    <measured sample rate 47952.00 Hz (-0.10%)>

*** All tests completed OK ***
audiols/fortyfive> uname -a
SunOS fortyfive 5.11 snv_119 sun4u sparc SUNW,A70

I'll go ahead and include SPARC support after all. Maybe someone with an Ultra 45 or 25 will like this.

AudigyLS Boomer Driver Posted

I've posted test binaries for the AudigyLS driver for Boomer systems. There is also a webrev posted. These are test binaries only! Use at your OWN RISK!

If you do use them, please let me know how it goes.

Thanks!

Surround Sound on SPARC?

I'm about ready to integrate the Audigy LS audio driver, which is a PCI add-in card that is capable of 5.1 surround sound. (I've been working on it in the "off" hours, as I currently have other higher priority projects that I'm working on while doing work on Sun's nickel; this explains why it has taken so long.)

I have one quick question: does anyone really want to have this work on SPARC systems? The only tangible advantages I could see for this are:

• If your internal audio device is busted, there is another alternative.
• If you have some compelling reason to want surround sound support on your SPARC system.

Right now because the effort to qualify and integrate takes a while, and because I hate the idea of integrating bloatware that nobody is going to use, I am not planning on integrating SPARC support for this driver. However, if at least one or two people speak up and tell me that this is something that they want, then I'm much more likely to take the time to do the work. (The driver should Just Work on SPARC, its mostly a matter of running the tests, which take a few hours.)

So, if this is something you want, let me know!

Community Contributions

I've recently (in the past week) integrated a small improvement from Roland ( so kernel code can use C99 booleans (supposedly there are performance gains for using this relative to boolean_t), and a major overhaul and conversion to GLDv3 for the legacy "dnet" driver from Steve Stallion.

I would like to thank both contributors for their patience. Neither of these was a particularly trivial integration. Steve in particular worked on this integration for quite a long time, due largely to the high cost of getting such a crufty driver to pass through NICDRV.

Fun With Rocketry

Well, today I finally got a model rocket set ... been wanting one since I was about 8 years old. Now that my son is that old, I finally can justify it. :-) The kids and I went to a park and set up 4 launches (well really 3, more on that later) of a single stage Estes rocket (A3-4T engines, IIRC ... basically about the smallest engines typically sold.) Total cost was about $30.

The kids really enjoyed it, and I can tell by the questions Timothy is asking that he's thinking about implementation -- he's definitely got the budding mind of an engineer. (How does the ejection charge work? What's the purpose of the recovery streamer? How do multistage rockets work? Etc.)

We did have one minor mishap, on our first launch attempt. Turns out that the rocket had wedged against the small plastic keeper, creating just enough friction to turn our launch into a static test. The engine burned a small hole, about 50 mm in diameter, right through the aluminum guard plate on the launcher; an amazing testament to the power of even these relatively tiny rocket engines. Needless to say, it definitely helped demonstrate the importance of all the safety measures I was stressing. :-)

The next three flights went off without a hitch. The product documentation says "up to 350 feet", but I think the peak heights looked higher than that.

For his 9th birthday in November, I'll probably invest in some other more sophisticated models. Its cool to be a kid again, but its even more cool to see your kid's eyes light up; who knew learning could be such fun!

Test Marvell Yukon 2 Ethernet Driver

I've posted a test version of my "yge" driver (Marvell Yukon Gigabit Ethernet, but it also supports some 100Mbps devices) up on OpenSolaris.org. Get it here -- get the file called yge-test.tar.gz.

There is a webrev posted too, if you want to beat your head against the wall.

If you do test this, be aware that many possible PCI ids are not in the installer file. If you want to test more, please do so (at your own risk). If you find that other devices either do work, or do not, please let me know -- send mail to garrett.damore at sun dot com.

Thanks, and enjoy! (I'm hoping to get this driver integrated into SNV 123.)

A Push A Long Time In Coming

I just pushed the changes associated with PSARC 2005/425, which is basically the removal of the script wrappers /usr/ucb/cc, /usr/ucb/lint, and /usr/ucb/ld. The fix will be in b122 of ON.

This is a good thing for people who build free software bits on OpenSolaris. For a long time, there have been complaints that /usr/ucb on your PATH was particularly toxic (some would say it was toxic anyway, but that's a different matter) -- autoconf scripts were frequently confounded by /usr/ucb/cc, which has done nothing more than generate a useless error message for most people.

So, /usr/ucb/ on your path, while not recommended, is at least no longer particularly toxic.

audiovia97 not as rare as I thought

So I was cleaning out my office.... (no jokes from the peanut gallery please!)

I was completely surprised to find that out of 5 old machines I was about to retire to the recycler, no fewer than three of them -- from totally different manufacturers -- one of them was Compaq Presario -- had integrated Via82c686 audio (which is supported by audiovia97.)

So if you've still got old Celeron's or PIII class systems around, there's a pretty good chance that you can get audio in OpenSolaris on them now.

Another way you know you're getting old...

When someone on facebook is confused and mixes up your H.S. graduation date with their birthday.

People born back when I was graduating high school are now graduates themselves.

Getting old sucks. But its better than the alternative.

ohloh.net

I found an interesting site; it tracks commits by developer, and potentially ranks them, using a "kudos" system. There's also a way to give and to receive "kudos". It also has some source code analysis for projects, though I don't necessarily agree with all that it does. (A project that is 50% comments is not inherently better than a project that is 10% lines... you can't judge code quality or readability or structure based on comments.)

Anyway, I just joined and made it aware of who I am... I have a "kudo" rank of 7. If anyone else here is using this service, I'd be curious to know about it. My account information is here.

Fast Reboot & Panic

I noticed that Sherry Moore just posted a blog entry about Fast Reboot.

I wanted to take a few moments to mention a few things, that I think folks should understand.

First off, the feature (fast reboot) is really useful -- for manually initiated reboots to perform administration (such as to reboot after installing new kernel bits or a critical patch), its wonderful to skip past the various hardware related initialization, and can really help with downtime costs associated with administrative maintenance tasks like patching.

This is especially true for systems with lots of peripheral buses (SCSI, Infiniband, etc.) that take a long time for low-level BIOS to probe and test. In such situations, BIOS initialization can consume several minutes. Reducing this to a few seconds is a compelling idea.

However, there are some gotchas that in my opinion people should be aware of when using the variant of this that gets used on panic().

• During a panic situation, all bets are off about kernel or hardware state. (This is why the code in the kernel called panic() after all -- it has deemed it unsafe to proceed.)
• So, the nice safe quiesce(9e) entry points are not guaranteed to be called. Hopefully they will be, but not necessarily.
• Some drivers may panic when they find hardware in a state that is beyond their ability to recover. So quiesce(9e) may be functionally unable to put the system back into a sane state.
• Some hardware simply can't restore properly without a low level PCI reset, which the current fast reboot code skips.
• If hardware is not quiesce(9e)'d properly, on the reboot, the new kernel can wind up in a situation where a device might be randomly scribbling (via DMA) to physical memory (this can lead to arbitrary data corruption of either kernel or user pages of memory), or might wind up with a stuck interrupt (which may exhibit as a hard hang of the machine).

Note that the above situations are not theoretical. I have hit these problems, involving various different bits of hardware ... certain framebuffers that require low level initialization, certain Ethernet parts that don't have a functional software reset mechanism, and a certain WiFi controller that can leave interrupts stuck.

However, all the situations described above are also quite unlikely to occur. They probably occur in fewer than 1% of all potential panic scenarios.

The upshot of this is that I would most definitely not use fast reboot on any machine that is in production or which has critical data. Do you want to Its a wonderful feature for kernel developers who trash their systems all the time and are accustomed to taking risks -- for such uses the shortened reboot time on a panic is a net win compared to the potential risks (which is virtually nil -- if a system I'm testing hard hangs or crashes a second time I can always just power cycle it), but in a production environment the expectations are different.

In such an environment, you really don't expect to see panic() occur (if it does, you're already on the path of a bug!), but when it does, you want to be 100% certain that you confine the potential damage and get back to a known safe (and good) state. This is why we panic() and reboot, after all. Eliding those time consuming steps of low-level initialization might at first sound like an attractive way to get to higher uptimes, but if you analyze the situation carefully, its a potentially riskier proposition that could (admittedly unlikely) cause much greater downtime.

Now that you know the concerns, you are of course free to make your own assessment.

If you do want to turn off fast reboot on panic (and I do recommend that you leave regular fast reboot on, as far as I can see there is no downside to making an administratively requested reboot go faster), then you can just use the following commands (which are taken from Sherry's blog posting):

        
    # svccfg -s "system/boot-config:default" \
               setprop config/fastreboot_onpanic=false
    # svcadm refresh svc:/system/boot-config:default

(Note that fast reboot on panic is enabled by default on OpenSolaris since build 112. However, since nobody should have deployed a system with this on in production -- we've had only development releases since then -- there is probably no urgency to go and immediately change your systems. Of course, that situation might be different if you're reading this blog post at some point in the future.)

Archived KCA 2009 Boomer Talk

As some people know, the KCA 2009 was streamed live. The video of my talk on Boomer was archived (as well as other talks) and is available on line.

You can watch it here.

Note that I highly recommend advancing to about 6:30 in the stream, because the first 6+ minutes was me struggling with laptop/projector incompatibilities. (Would be nice if the folks that posted the video could crop that meaningless bit out.)

Other thoughts I had from looking back and reviewing this (which I did for the first time yesterday):

• A live demo would make it more interesting.
• Test the equipment compatibility first when presenting.
• Turn off screen savers.
• Rehearse the talk before hand.
• Some points were repeated, which was unfortunate since I had to rush or skip other points.
• Practice talking more.. especially at the beginning it seems like I didn't know what to do with my hands.
• Don't be afraid to get out from behind the podium.
• The podium itself was poorly situated ... the exit sign above my head was particularly apropros framing.

I'd be happy to hear other constructive criticisms, whether on Boomer, the paper, slides, or my presentation style. I don't get the chance to speak in public often, so when I do I'd like to be better at it then I think I managed this time.

audiovia97 pushed

I've pushed the audiovia97 device driver. Those of you with Via 82C686 south bridges will be able to make use of your on-board audio in OpenSolaris builds 121 and beyond. Enjoy.

Boomer Paper at KCA

I presented a paper covering Boomer at Kernel Conference Australia 2009. I've made the paper and slides available for your enjoyment.

Off to Brisbane, Austrialia

I'm headed to Brisbane for the week -- I'm presenting at Kernel Conference Australia 2009. I hope to meet other like minded UNIX kernel nerds there. Maybe do some snorkeling as well, although its the off-season there. (But it can hardly be colder than the water in California...)

STREAMS and non-STREAMS in the same driver

Some of you kernel hackers may be interested to know about my case (PSARC 2009/380) that eliminates one of the ancient limitations of Solaris -- having STREAMS and non-STREAMS entry points in the same device driver. I've also implemented it and am waiting for the case to time out before I submit the RTI.

As part of this, I also implemented a set of changes to the audio stack -- the austr(7D) "speecial" node and driver goes away, and the Sun audio personality sheds about 1,000 lines of complexity. I'll be pushing those changes later, once I've gotten code review feedback. (If you review the changes, please let me know!)