You are not really supposed to run QEMU directly if you are looking for that kind of experience, that's why libvirt exists. Other than that, QEMU should really be a generic emulator rather than being infested with platform-specific stuff, everything else should be independently maintained and pluggable. (Autodetection is also extremely fragile, and takes away from keeping a VM a VM)
But it would be easy to design qemu to have 1000+ config options which are on/off/auto settings, and the 'auto' mode is autodetected based on which OS is probably running.
Nothing stops someone overriding some or all of those flags to whatever values they like. It's still a power user tool, just one that also 'just works' for common usecases of people who don't want to manually set the IRQ number for the DMA controller by hand...
> But it would be easy to design qemu to have 1000+ config options which are on/off/auto settings, and the 'auto' mode is autodetected based on which OS is probably running.
That would add a ton of new responsibility to a codebase that so far has been doing none of this. It would have to be aware of different operating systems, operating system image formats for autodetection, OS releases and their corresponding quirks, ... And some way to test this, and test this automatically, so that this stuff doesn't immediately rot away. People would begin to depend on this, and any change in this behaviour would be a breaking bug, and would introduce implicit stability contracts for complex scenarios.
Let qemu be low-level emulator and make zero assumptions about how it's being used - that makes life so much easier for those of us who integrate it into non-standard scenarios. Libvirt gives you everything needed for typical 'I wanna run a commercial OS in a VM on my desktop/server', and can afford to make assumptions about its usage scenario.
