[RFC] modular dependencies for kvm's qemu

[RFC] modular dependencies for kvm's qemu

[Carlo Marcelo Arenas Belon]

Greetings,

kvm's configure calls qemu's configure with --enable-alsa, making the
existence and use of alsa a dependency; with the import of the latest CVS
qemu, a similar implicit dependency has been added for gnutls (required for
TLS support for qemu's vnc server).

the following proposed patch (which is a combined patch from a 2 patch series)
allows kvm's configure to enable alsa or disable vnc tls conditionally.

I am curious if the approach taken for alsa (which is the one that fits what
qemu's configure allows for this case) is acceptable or not, as it will change
the dependency on alsa from being required by default to optional and unless 
--enable-alsa is used.

Carlo
---
--- kvm-46/configure	2007-10-09 11:43:12.000000000 -0700
+++ kvm-46/configure	2007-10-16 01:40:32.000000000 -0700
@@ -16,6 +16,8 @@
 	    --with-patched-kernel  don't use external module
 	    --kerneldir=DIR        kernel build directory ($kerneldir)
 	    --qemu-cc="$qemu_cc"   compiler for qemu (needs gcc3.x) ($qemu_cc)
+	    --enable-alsa          enable alsa support for qemu
+	    --disable-vnc-tls	   disable vnc tls support for qemu
 	    --disable-gcc-check    don't insist on gcc-3.x
                                    - this will break running without kvm
 EOF
@@ -50,6 +52,12 @@
 	--qemu-cc)
 	    qemu_cc="$arg"
 	    ;;
+	--enable-alsa)
+	    enable_alsa=1
+	    ;;
+	--disable-vnc-tls)
+	    disable_vnc_tls=1
+	    ;;
 	--disable-gcc-check)
 	    disable_gcc_check=1
 	    ;;
@@ -85,7 +93,8 @@
     --disable-kqemu --extra-cflags="-I $PWD/../user" \
     --extra-ldflags="-L $PWD/../user" \
     --enable-kvm --kernel-path="$libkvm_kerneldir" \
-    --enable-alsa \
+    ${enable_alsa:+"--enable-alsa"} \
+    ${disable_vnc_tls:+"--disable-vnc-tls"} \
     ${disable_gcc_check:+"--disable-gcc-check"} \
     --prefix="$prefix"
 )

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [RFC] modular dependencies for kvm's qemu

[Avi Kivity]

Carlo Marcelo Arenas Belon wrote:
> Greetings,
>
> kvm's configure calls qemu's configure with --enable-alsa, making the
> existence and use of alsa a dependency; with the import of the latest CVS
> qemu, a similar implicit dependency has been added for gnutls (required for
> TLS support for qemu's vnc server).
>
> the following proposed patch (which is a combined patch from a 2 patch series)
> allows kvm's configure to enable alsa or disable vnc tls conditionally.
>
> I am curious if the approach taken for alsa (which is the one that fits what
> qemu's configure allows for this case) is acceptable or not, as it will change
> the dependency on alsa from being required by default to optional and unless 
> --enable-alsa is used.
>
>  EOF
> @@ -50,6 +52,12 @@
>  	--qemu-cc)
>  	    qemu_cc="$arg"
>  	    ;;
> +	--enable-alsa)
> +	    enable_alsa=1
> +	    ;;
> +	--disable-vnc-tls)
> +	    disable_vnc_tls=1
> +	    ;;
>   

The variables should be initialized so they aren't accidentally picked 
up from the environment.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [RFC] modular dependencies for kvm's qemu

[Daniel P. Berrange]

On Tue, Oct 16, 2007 at 04:22:14AM -0500, Carlo Marcelo Arenas Belon wrote:
> Greetings,
> 
> kvm's configure calls qemu's configure with --enable-alsa, making the
> existence and use of alsa a dependency; with the import of the latest CVS
> qemu, a similar implicit dependency has been added for gnutls (required for
> TLS support for qemu's vnc server).
> 
> the following proposed patch (which is a combined patch from a 2 patch series)
> allows kvm's configure to enable alsa or disable vnc tls conditionally.
> 
> I am curious if the approach taken for alsa (which is the one that fits what
> qemu's configure allows for this case) is acceptable or not, as it will change
> the dependency on alsa from being required by default to optional and unless 
> --enable-alsa is used.

So why don't you use  --disable-alsa in the patch instead. It seems like rather
a bad idea to suddenly switch the configure script defaults in the way you 
suggest for alsa. It really wouldn't be much harder to set enable_alsa=1
in the top of configure, and then have the flag toggle it to off.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [RFC] modular dependencies for kvm's qemu

[Carlo Marcelo Arenas Belon]

On Tue, Oct 16, 2007 at 02:39:30PM +0100, Daniel P. Berrange wrote:
> On Tue, Oct 16, 2007 at 04:22:14AM -0500, Carlo Marcelo Arenas Belon wrote:
> > I am curious if the approach taken for alsa (which is the one that fits what
> > qemu's configure allows for this case) is acceptable or not, as it will change
> > the dependency on alsa from being required by default to optional and unless 
> > --enable-alsa is used.
> 
> So why don't you use  --disable-alsa in the patch instead.

because the only option available in qemu is to enable alsa with that flag;
there is no --disable-alsa in qemu's configure unless we add one (*).

> It seems like rather
> a bad idea to suddenly switch the configure script defaults in the way you 
> suggest for alsa. It really wouldn't be much harder to set enable_alsa=1
> in the top of configure, and then have the flag toggle it to off.

ok, but if that is added to kvm's configure then the logic will be inversed
when looking at qemu's configure, probably confusing users.

on the other hand, if --disable-alsa is added to qemu's configure so that it
can be used with the same logic in both sides then the objective of trying to
keep the qemu changes to a minimum will be violated.

hence why I though that changing the default (which seemed arbitrary at least)
was probably the lesser of all evils.

Carlo

(*) qemu's configure is not coming from autotools but is a custom script that
performs a similar function that an autoconf'ed configure would do but not
with all the functionality you would usually expect for it.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [RFC] modular dependencies for kvm's qemu

[Avi Kivity]

Carlo Marcelo Arenas Belon wrote:
>   
>> It seems like rather
>> a bad idea to suddenly switch the configure script defaults in the way you 
>> suggest for alsa. It really wouldn't be much harder to set enable_alsa=1
>> in the top of configure, and then have the flag toggle it to off.
>>     
>
> ok, but if that is added to kvm's configure then the logic will be inversed
> when looking at qemu's configure, probably confusing users.
>
>   

If audio output is going to sdl anyway, then this has no effect on most 
users, right?

If so I prefer being closer to qemu as you suggest.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [RFC] modular dependencies for kvm's qemu

[Anthony Liguori]

Avi Kivity wrote:
> Carlo Marcelo Arenas Belon wrote:
>   
>>   
>>     
>>> It seems like rather
>>> a bad idea to suddenly switch the configure script defaults in the way you 
>>> suggest for alsa. It really wouldn't be much harder to set enable_alsa=1
>>> in the top of configure, and then have the flag toggle it to off.
>>>     
>>>       
>> ok, but if that is added to kvm's configure then the logic will be inversed
>> when looking at qemu's configure, probably confusing users.
>>
>>   
>>     
>
> If audio output is going to sdl anyway, then this has no effect on most 
> users, right?
>   

Yes.

> If so I prefer being closer to qemu as you suggest.
>   

Me too.

Regards,

Anthony Liguori



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [RFC] modular dependencies for kvm's qemu

[Carlo Marcelo Arenas Belon]

On Tue, Oct 16, 2007 at 04:20:37PM +0200, Avi Kivity wrote:
> Carlo Marcelo Arenas Belon wrote:
> >  
> >>It seems like rather
> >>a bad idea to suddenly switch the configure script defaults in the way 
> >>you suggest for alsa. It really wouldn't be much harder to set 
> >>enable_alsa=1
> >>in the top of configure, and then have the flag toggle it to off.
> >
> >ok, but if that is added to kvm's configure then the logic will be inversed
> >when looking at qemu's configure, probably confusing users.
> 
> If audio output is going to sdl anyway, then this has no effect on most 
> users, right?

it probably wouldn't work out of the box, unless they change

QEMU_AUDIO_DRV=alsa

to :

QEMU_AUDIO_DRV=sdl
SDL_AUDIODRIVER=alsa

but I never had sound support configured so I am no way expert and can't test
if that is the case or if that is the way it fallsback (will take a closer
look at the code later though).

> If so I prefer being closer to qemu as you suggest.

you mean closer as on using the same syntax, or closer as on avoiding changing
qemu unless absolutely needed?

Carlo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [RFC] modular dependencies for kvm's qemu

[Avi Kivity]

Carlo Marcelo Arenas Belon wrote:
>
>> If so I prefer being closer to qemu as you suggest.
>>     
>
> you mean closer as on using the same syntax, or closer as on avoiding changing
> qemu unless absolutely needed?
>
>   

Both.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [RFC] modular dependencies for kvm's qemu

[Anthony Liguori]

Carlo Marcelo Arenas Belon wrote:
> On Tue, Oct 16, 2007 at 04:20:37PM +0200, Avi Kivity wrote:
>   
>> Carlo Marcelo Arenas Belon wrote:
>>     
>>>  
>>>       
>>>> It seems like rather
>>>> a bad idea to suddenly switch the configure script defaults in the way 
>>>> you suggest for alsa. It really wouldn't be much harder to set 
>>>> enable_alsa=1
>>>> in the top of configure, and then have the flag toggle it to off.
>>>>         
>>> ok, but if that is added to kvm's configure then the logic will be inversed
>>> when looking at qemu's configure, probably confusing users.
>>>       
>> If audio output is going to sdl anyway, then this has no effect on most 
>> users, right?
>>     
>
> it probably wouldn't work out of the box, unless they change
>
> QEMU_AUDIO_DRV=alsa
>   

If alsa support is compiled in, then alsa will be preferred over SDL.  
As long as SDL is supported in the build (which is the default), then 
you will be able to at least use alsa.  Whatever SDL uses by default 
depends on what the configuration is.  IMHO, just relying on SDL to pick 
the Right Thing is best because that's a choice that was made by the 
distribution so presumably it's whatever works the best on the given system.

Regards,

Anthony Liguori

> to :
>
> QEMU_AUDIO_DRV=sdl
> SDL_AUDIODRIVER=alsa
>
> but I never had sound support configured so I am no way expert and can't test
> if that is the case or if that is the way it fallsback (will take a closer
> look at the code later though).
>
>   
>> If so I prefer being closer to qemu as you suggest.
>>     
>
> you mean closer as on using the same syntax, or closer as on avoiding changing
> qemu unless absolutely needed?
>
> Carlo
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [RFC] modular dependencies for kvm's qemu

[Carlo Marcelo Arenas Belon]

On Tue, Oct 16, 2007 at 10:36:03AM -0500, Carlo Marcelo Arenas Belon wrote:
> On Tue, Oct 16, 2007 at 04:20:37PM +0200, Avi Kivity wrote:
> > Carlo Marcelo Arenas Belon wrote:
> > >  
> > >>It seems like rather
> > >>a bad idea to suddenly switch the configure script defaults in the way 
> > >>you suggest for alsa. It really wouldn't be much harder to set 
> > >>enable_alsa=1
> > >>in the top of configure, and then have the flag toggle it to off.
> > >
> > >ok, but if that is added to kvm's configure then the logic will be inversed
> > >when looking at qemu's configure, probably confusing users.
> > 
> > If audio output is going to sdl anyway, then this has no effect on most 
> > users, right?
> 
> it probably wouldn't work out of the box, unless they change
> 
> QEMU_AUDIO_DRV=alsa
> 
> to :
> 
> QEMU_AUDIO_DRV=sdl
> SDL_AUDIODRIVER=alsa
> 
> but I never had sound support configured so I am no way expert and can't test
> if that is the case or if that is the way it fallsback (will take a closer
> look at the code later though).

for the cases where qemu doesn't have alsa support but the environment
variables point to using alsa, then it will complain with :

  audio: Unknown audio driver 'alsa'
  audio: Run with -audio-help to list available drivers

but then it will scan for an available audio driver it can use by default and
configure SDL instead, probably with alsa support if that is available, as 
done explicitly by the second set of environment variables.

tested it with a 64bit linux host running a 32bit windows 2000 advanced server
guest using -soundhw sb16.

in a hopefully unrelated note, using alsa directly wouldn't work as well as
using alsa through SDL, so I guess that the impact on the users is actually
positive if using SDL is also more reliable.

anyone with more audio experience care to comment?

Carlo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/