Re: qemu 4.2.0 audiodev soundhw

[BALATON Zoltan]

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:

https://lists.nongnu.org/archive/html/qemu-ppc/2020-04/msg00324.html

or this forum post:

https://www.emaculation.com/forum/viewtopic.php?f=34&t=10598

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.

Regards,
BALATON Zoltan