Re: [kvm-devel] [RFC] modular dependencies for kvm's qemu
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/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] modular dependencies for kvm's qemu
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@lists.sourceforge.net > 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/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] modular dependencies for kvm's qemu
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/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] modular dependencies for kvm's qemu
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/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] modular dependencies for kvm's qemu
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/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] modular dependencies for kvm's qemu
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/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] modular dependencies for kvm's qemu
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/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] modular dependencies for kvm's qemu
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/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] modular dependencies for kvm's qemu
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/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [RFC] modular dependencies for kvm's qemu
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/configure2007-10-09 11:43:12.0 -0700
+++ kvm-46/configure2007-10-16 01:40:32.0 -0700
@@ -16,6 +16,8 @@
--with-patched-kernel don't use external module
--kerneldir=DIRkernel 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-checkdon'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/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
