[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qemu 4.2.0 audiodev soundhw

From: BALATON Zoltan
Subject: Re: qemu 4.2.0 audiodev soundhw
Date: Wed, 22 Apr 2020 21:48:09 +0200 (CEST)
User-agent: Alpine 2.22 (BSF 395 2020-01-19)

On Wed, 22 Apr 2020, Philippe Mathieu-Daudé wrote:
Hi Jakob,

On 4/21/20 12:06 AM, Jakob Bohm wrote:

In fact, over the years, I have found it excruciatingly difficult to find
valid qemu documentation, as each feature effort tends to leave behind
half-updated pages and a bunch of uncoordinated messages about what may or
may not have been implemented in unspecified versions.
I feel your pain and agree.

How can this get improved?

Keeping the command line backward compatible is not an easy task.

There is a quite important effort in progress to improve the documentation.

Users reporting bad/incomplete/outdated documentation would help and motivate developers to fix it. That would reduce the gap between developers implementing features and users.

Do you other have suggestions about what should be improved?

Not related to audio but something as simple as adding a disk is almost impossible for a newbie. See this thread for example:


or this forum post:


This should be easy to do but even I don't know what's the preferred option now and how to use it correctly. Fortunately the -hda and -cdrom options still work for some machines, although they produce a warning which I tend to ignore as long as it works or go for the long way which is impossible to type so I have to save it in a script:

-drive if=none,id=hd,file=harddisk.img,format=raw \
-device ide-hd,drive=hd,bus=ide.0

Probably there should be some sensible way to use QEMU from the command line and have some options that work and won't change all the time.

The current situation may be because the CLI and monitor interface that are primarily human interfaces are abused by management software as an API although probably those should use some real API instead to control QEMU and leave the human interface to humans which then can be less arcane and have more convenience options. However splitting human and software interfaces would probably result in them diverging and human interface being neglected and bitrotting so these should be somehow still based on some common ground and any change in machine interface should make sure human interface is not broken by it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]