qemu discuss - May 2008 - PSARC 2008/261 EOF: Sound Blaster Pro driver sbpro

Garrett D''Amore wrote:
> Roland Mainz wrote:
> > Garrett D''Amore wrote:
> >> This case was approved yesterday.
> >
> > Erm... did you check whether this driver may be needed by software
> > emulators ? For example the only sound driver which AFAIK works in
Bochs
> > with Solaris as guest is "sbpro" (see
> >
http://www.koders.com/cpp/fid1239096CB8FECB28659D1411619E101856D78C07.aspx
> > ; and did you check "qemu", "VMware",
"Parallels" etc. yet ?).
> 
> Yes, for some of these, sbpro is required.  But the mainstream VMs have
> moved on to newer emulations:
> 
> Notably:
> 
> * VirtualBox: emulates AC''97
> * Parallels: emulates AC''97
> * VMware: emulates AudioPCI, audio not supported on Solaris today -- may
> add AudioPCI driver for it in the future
> * VirtualPC: Microsoft product, does not support Solaris (at least
> officially)
> * qemu: May require sbpro or audiopci -- some evidence that it may also
> support ac''97.  (Vanishingly small market share.)
Erm... we have a QEmu projet at opensolaris.org - did you ask them
whether they like the removal ?
> * bochs: Does anyone actually *care*?  It requires OSS in any case, so
> would not represent a regression.  (Notably the sb16 emulation in bochs
> is very close to unusable due to heave CPU requirements.)
That''s why I added --enable-idle-hack to Bochs long ago to deal with
the
CPU hogging, together with all the other fixes to make Solaris bootable
on Bochs (e.g. SPARC as host, x86 as guest) ...

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix
programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)

Roland Mainz wrote:
> Garrett D''Amore wrote:
>   
>> Roland Mainz wrote:
>>     
>>> Garrett D''Amore wrote:
>>>       
>>>> This case was approved yesterday.
>>>>         
>>> Erm... did you check whether this driver may be needed by software
>>> emulators ? For example the only sound driver which AFAIK works in
Bochs
>>> with Solaris as guest is "sbpro" (see
>>>
http://www.koders.com/cpp/fid1239096CB8FECB28659D1411619E101856D78C07.aspx
>>> ; and did you check "qemu", "VMware",
"Parallels" etc. yet ?).
>>>       
>> Yes, for some of these, sbpro is required.  But the mainstream VMs have
>> moved on to newer emulations:
>>
>> Notably:
>>
>> * VirtualBox: emulates AC''97
>> * Parallels: emulates AC''97
>> * VMware: emulates AudioPCI, audio not supported on Solaris today --
may
>> add AudioPCI driver for it in the future
>> * VirtualPC: Microsoft product, does not support Solaris (at least
>> officially)
>> * qemu: May require sbpro or audiopci -- some evidence that it may also
>> support ac''97.  (Vanishingly small market share.)
>>     
>
> Erm... we have a QEmu projet at opensolaris.org - did you ask them
> whether they like the removal ?
>   
No.  But I wasn''t aware of it until you just mentioned it. 
I''ll ask
there now.  If it turns out that removal is problematic, I can always 
just drop the case.  (But sbpro is painful because its a closed source 
driver without any open source alternatives, and would seriously hamper 
our efforts to integrate OSS.)

    -- Garrett
>   
>> * bochs: Does anyone actually *care*?  It requires OSS in any case, so
>> would not represent a regression.  (Notably the sb16 emulation in bochs
>> is very close to unusable due to heave CPU requirements.)
>>     
>
> That''s why I added --enable-idle-hack to Bochs long ago to deal
with the
> CPU hogging, together with all the other fixes to make Solaris bootable
> on Bochs (e.g. SPARC as host, x86 as guest) ...
>
> ----
>
> Bye,
> Roland
>
>

Garrett D''Amore wrote:
> Roland Mainz wrote:
>> Garrett D''Amore wrote:
>>  
>>> Roland Mainz wrote:
>>>    
>>>> Garrett D''Amore wrote:
>>>>      
>>>>> This case was approved yesterday.
>>>>>         
>>>> Erm... did you check whether this driver may be needed by
software
>>>> emulators ? For example the only sound driver which AFAIK works
in
>>>> Bochs
>>>> with Solaris as guest is "sbpro" (see
>>>>
http://www.koders.com/cpp/fid1239096CB8FECB28659D1411619E101856D78C07.aspx
>>>>
>>>> ; and did you check "qemu", "VMware",
"Parallels" etc. yet ?).
>>>>       
>>> Yes, for some of these, sbpro is required.  But the mainstream VMs
have
>>> moved on to newer emulations:
>>>
>>> Notably:
>>>
>>> * VirtualBox: emulates AC''97
>>> * Parallels: emulates AC''97
>>> * VMware: emulates AudioPCI, audio not supported on Solaris today
-- may
>>> add AudioPCI driver for it in the future
>>> * VirtualPC: Microsoft product, does not support Solaris (at least
>>> officially)
>>> * qemu: May require sbpro or audiopci -- some evidence that it may
also
>>> support ac''97.  (Vanishingly small market share.)
>>>     
>>
>> Erm... we have a QEmu projet at opensolaris.org - did you ask them
>> whether they like the removal ?
>>   
> 
> No.  But I wasn''t aware of it until you just mentioned it. 
I''ll ask
> there now.  If it turns out that removal is problematic, I can always 
> just drop the case.  (But sbpro is painful because its a closed source 
> driver without any open source alternatives, and would seriously hamper 
> our efforts to integrate OSS.)
Not to mention that we would like to remove any ISA device support for 
non-legacy devices.  Add-in ISA devices do not work well in current versions 
of Solaris due to lack of PnP support.

Mike

I don''t think qemu, even if though there is an opensolaris.org hosted 
project to ensure it runs on OpenSolaris, should hold up removal of this 
driver.

Think about it this way, given all the OpenSolaris on metal and all the 
other whole machine virtualisation solutions that are available how 
important it is that qemu have sound ?  Removal of this driver isn''t 
going to break qemu support for Solaris as a guest it just means that 
qemu OpenSolaris guests after this putback won''t have sound support.

Is that really such a big deal ?

 From an architecture view I think this case is well researched and on 
solid ground.   The qemu sound issue if it is really that important is a 
business choice not an ARC one and the value of keeping around such an 
old ISA driver would need to be justified to the Solaris PAC.

Distributions other than the binary OpenSolaris and Sun''s distros are 
free to hold on to this legacy driver and its support if they really 
wish to.

In my opinion this case remains closed.

--
Darren J Moffat

On Fri, May 30, 2008 at 7:21 AM, Darren J Moffat <Darren.Moffat at
sun.com> wrote:
> I don''t think qemu, even if though there is an opensolaris.org
hosted
> project to ensure it runs on OpenSolaris, should hold up removal of this
> driver.
>
> Think about it this way, given all the OpenSolaris on metal and all the
> other whole machine virtualisation solutions that are available how
> important it is that qemu have sound ?  Removal of this driver
isn''t
> going to break qemu support for Solaris as a guest it just means that
> qemu OpenSolaris guests after this putback won''t have sound
support.
>
> Is that really such a big deal ?
>
>  From an architecture view I think this case is well researched and on
> solid ground.   The qemu sound issue if it is really that important is a
> business choice not an ARC one and the value of keeping around such an
> old ISA driver would need to be justified to the Solaris PAC.
>
> Distributions other than the binary OpenSolaris and Sun''s distros
are
> free to hold on to this legacy driver and its support if they really
> wish to.
>
> In my opinion this case remains closed.
I am incliined to agree.  I have always used the ess1371 driver which
is (to my knowledge) a PCI based audio HW.

Ben

Ben Taylor wrote:
> On Fri, May 30, 2008 at 7:21 AM, Darren J Moffat <Darren.Moffat at
sun.com> wrote:
>   
>> I don''t think qemu, even if though there is an opensolaris.org
hosted
>> project to ensure it runs on OpenSolaris, should hold up removal of
this
>> driver.
>>
>> Think about it this way, given all the OpenSolaris on metal and all the
>> other whole machine virtualisation solutions that are available how
>> important it is that qemu have sound ?  Removal of this driver
isn''t
>> going to break qemu support for Solaris as a guest it just means that
>> qemu OpenSolaris guests after this putback won''t have sound
support.
>>
>> Is that really such a big deal ?
>>
>>  From an architecture view I think this case is well researched and on
>> solid ground.   The qemu sound issue if it is really that important is
a
>> business choice not an ARC one and the value of keeping around such an
>> old ISA driver would need to be justified to the Solaris PAC.
>>
>> Distributions other than the binary OpenSolaris and Sun''s
distros are
>> free to hold on to this legacy driver and its support if they really
>> wish to.
>>
>> In my opinion this case remains closed.
>>     
>
> I am incliined to agree.  I have always used the ess1371 driver which
> is (to my knowledge) a PCI based audio HW.
>   
Yes.  If ess1371 is available, then it will use the audioens driver, and 
we are good to go.  (The problem is that older ess1370 - as opposed to 
ess1371 -- is not supported right now.   If it is necessary for 
virtualization -- and VMware may be a case where we need/want it --  
then we can add a driver for it when we finish the OSS project.  There 
is an OSS driver for both 1370 and 1371 hardware.)

    -- Garrett
> Ben
>

Thank you, Darren.

If it becomes an issue, we can look into providing (or the community can 
provide) a driver for ess1370, which I believe is at least one 
alternative for qemu.  (It would be easy enough to do this, actually. 
The driver is already available in 4Front''s OSS distribution.)

For sbpro itself, distributions may have issues.  The source code is not 
open, and I''m not entirely sure whether the binary is redistributable
or
not.

For us, keeping the old sbpro driver around really isn''t an option for 
the future.  For one, we simply lack the ability to test it with 
anything other than virtualized hardware.

    -- Garrett

Darren J Moffat wrote:
> I don''t think qemu, even if though there is an opensolaris.org
hosted
> project to ensure it runs on OpenSolaris, should hold up removal of 
> this driver.
>
> Think about it this way, given all the OpenSolaris on metal and all 
> the other whole machine virtualisation solutions that are available 
> how important it is that qemu have sound ?  Removal of this driver 
> isn''t going to break qemu support for Solaris as a guest it just
means
> that qemu OpenSolaris guests after this putback won''t have sound
support.
>
> Is that really such a big deal ?
>
> From an architecture view I think this case is well researched and on 
> solid ground.   The qemu sound issue if it is really that important is 
> a business choice not an ARC one and the value of keeping around such 
> an old ISA driver would need to be justified to the Solaris PAC.
>
> Distributions other than the binary OpenSolaris and Sun''s distros
are
> free to hold on to this legacy driver and its support if they really 
> wish to.
>
> In my opinion this case remains closed.
>
> -- 
> Darren J Moffat