(I'm not on this list, so any relevant replies need to come directly to me.)
I'm the technical lead for the effort to integrate OSS technology into
Solaris.
I've been informed that there were some questions about the integration
of OSS into Nevada, and questions about our direction.
I'll be posting a lot more detail about this all in the coming month (we
need to get our materials together to come to PSARC), but I wanted to
take a few minutes to address one outstanding question that was recently
asked here, which is why we don't just integrate OSS as-is.
The answer here is that OSS is simply not up to snuff. While for many
users the increased device support winds up making OSS an improvement
over our legacy audio stack, there are significant areas where OSS falls
gravely short and would wind up with significant regressions. Many of
these regressions are not likely to be noticed by average consumers,
some of them *might* be. An example area where OSS falls down on its
face is support for the suspend-to-ram, and the new fast reboot
interfaces. OSS would break those features. (And some of those
features are very important to OpenSolaris users!)
Additionally, in some non-trivial areas OSS drivers represent potential
regression in hardware support. For example, there is simply no audiocs
driver for SPARC systems, no Sun Ray drivers, and the hdaudio driver
that is part of OSS has some serious stability concerns. (For some
hardware configurations it either fails to operate properly, can cause
panics, and may misreport audio controls.) Another example is USB
audio, where the OSS architecture can't support the same audio control
interfaces (because its not a streams driver, it can't support plumbing
a HID module on top of the stream device like Sun audio can), and the
devices supported are different from those supported by Sun's driver.
(The USB audio driver in OSS is also extremely fragile, simple hot plug
operations have been known to cause hangs or panics in our testing.)
For Sun audio interfaces, the OSS stack also represents potential
feature regression -- software such as sdtaudiocontrol may not be able
to manage important features such as volume control, etc.
So, those are the reason's why OSS isn't integrating as-is.
In fact, what we have done is licensed the OSS technology from 4Front,
and are involved with a major rewrite of the Solaris audio framework,
using significant parts imported from OSS, as well as portions imported
from the legacy stack. Our goals are 100% compatibility with existing
Sun audio, no feature regressions, support for userland OSS APIs,
expanded device support, greatly improved ease of incorporating new OSS
drivers (the new audio DDI is much more similar to the OSS driver
interface), support for new features (specifically high def audio and
multichannel support in phase 1, later phases may add SPDIF pass-thru
etc.), native STREAMS support, full support for audio in Linux branded
zones, improved scalability (OSS can't do Sun compatibility for more
than one device on the system, and has a lot of builtin limits in the
form of fixed arrays, etc.) and a highly performant design (we've made a
*lot* of performance improvements and optimizations to greatly simplify
the "hot" path and minimize expensive mathematical conversions that OSS
does for every interrupt.)
So, the next major question I suppose is when are we going to have stuff
ready for testing and what not.
Well, obviously we're not going to be ready for delivery into
OpenSolaris 2008.11. HOWEVER, I hope that in November we will have
binaries and source available for folks to play with. (We're still
doing development in house, and the last month has been extremely
productive -- already we're able to use a number of popular audio
applications for testing, etc. - but there is still some important
missing functionality which we need to address before we offer it for
outside beta testing.) Integration will happen early next year, and
with the resulting product being available in the planned April release
of OpenSolaris.
A lot more detail will be presented later this month in the form of an
open PSARC case. If you have more specific concerns, I'd encourage you
to contact me directly.
-- Garrett
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
