[Pkg-xen-devel] [patch] Activate Qemu options
thomas at goirand.fr
Thu Sep 1 11:39:44 UTC 2011
On 09/01/2011 03:48 PM, Ian Campbell wrote:
> On Thu, 2011-09-01 at 15:29 +0800, Thomas Goirand wrote:
>> On 08/30/2011 06:49 PM, Ian Campbell wrote:
>>> On Mon, 2011-08-29 at 17:51 +0800, Thomas Goirand wrote:
>>>> This patch makes it possible for Qemu to use the SDL library, to
>>>> conveniently replace VNC, which has horrible mouse support.
>>>> It also adds a IOEMU_CONFIGURE_OPTIONS option in tools/Makefile, so that
>>>> later on, we can call:
>>>> $(MAKE_CLEAN) -C $(DIR)/tools $(CONFIG)
>>>> IOEMU_CONFIGURE_OPTIONS="--audio-drv-list=\"pa oss alsa sdl esd\"
>>>> --audio-card-list=\"ac97 es1370 sb16 cs4231a adlib gus\" --enable-mixemu"
>>>> from debian/rules.real
>>> That's quite an extensive list of audio devices. Where did it come from?
>>> Do we really need to be emulating adlib and gus for example? Are people
>>> really virtualising OSes of that era with the expectation that audio
>>> will work/be useful?
>>> The default list appears to be "ac97 es1370 sb16" which seems much more
>>> reasonable. Remember that each additional device-model adds to the
>>> security attack surface which is of particular interest for ones which
>>> are not commonly used by the rest of the qemu universe.
>>> In practical terms do you activate these using the dm_extra_args stuff
>>> or something else?
>> No, you do an export of some variable so that qemu knows about what you
>> want. I'll disable adlib and gus if you think it's a security issue, but
>> I believe it's a shame to have options and not use them. It'd be quite
>> nice to use Xen for example, to emulate old DOS machines, play old
>> games, or old demos...
> sb16 emulation ought to be sufficient to cover those uses cases I think?
> In any case I'd have though dosbox would be a better tool for that
> particular job.
>>> --- xen-4.1.1.orig/qemu/audio/sdlaudio.c
>>> +++ xen-4.1.1/qemu/audio/sdlaudio.c
>>> Is that the correct path, shouldn't this be a patch of a patch in
>>> debian/patches or something?
>>>> @@ -21,8 +21,8 @@
>>>> * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>>>> * THE SOFTWARE.
>>>> -#include <SDL.h>
>>>> -#include <SDL_thread.h>
>>>> +#include <SDL/SDL.h>
>>>> +#include <SDL/SDL_thread.h>
>>>> #include "qemu-common.h"
>>>> @@ -67,6 +67,8 @@ CFLAGS += -DCONFIG_PASSTHROUGH
>>>> $(info === PCI passthrough capability has been enabled ===)
>>>> +LIBS += -lpulse -lSDL
>>> These all seem a bit suspicious to me. Qemu's configure script contains
>>> runes which call sdl_config to obtain correct CFLAGS and LIBS entries
>>> for the library as well as code to detect a suitable version of sdl etc.
>>> Is --enable-sdl not sufficient?
>> Unless I'm mistaking, there's no such option such as --enable-sdl.
> So there isn't, just --disable-sdl.
> However the configure file seems to default to auto detecting sdl and
> enables it if the required libraries etc are present. AFAICT simply
> having the libsdl-dev package in the build-depends should be sufficient
> to enable sdl support. I've just confirmed that installing libsdl-dev on
> my Debian machines causes qemu to DTRT and enable SDL.
But if I don't add:
LIBS += -lpulse -lSDL
then I have a link error. I agree it'd be nice to have this in the
./configure script, but it's kind of messy in there. I've search for
"-lSDL" in the file and didn't find it anywhere in there (even grep -r
lSDL * wont find anything). Do you have an idea where/how to patch
better? And for pulse?
More information about the Pkg-xen-devel