On Fri, 21 Jun 2019 at 20:04, Cleber Rosa <cr...@redhat.com> wrote: > The experience acquired here deserves the highest consideration, but I > can't help myself to wonder if this isn't one of the (conceptual) > reasons for parameters such as '-nodefaults'. I know QEMU doesn't > promise the same behavior across different targets, but that could > improve considerably with very cheap actions.
Yeah, there are probably improvements we could make. The usual constraints apply: * we don't want to break compatibility with existing used command lines in the wild * ideally, we should be consistent across target architectures and across machine types about how things work (this is an ideal we obviously don't live up to today in many places) * we don't want to back ourselves into awkward corners for the future (the qemu-system-arm default machine type was originally 'integratorcp' which no doubt made sense in 1998 or whenever it was, but was nothing but confusing and the wrong choice for 99% of users by a decade or so later. x86 is kind of an outlier for having such longevity of "all hardware looks basically the same".) > You can consider me biased (I do consider myself), but trying to wear > the hat of a user first interacting with QEMU, I would expect a (any) > reasonably capable environment that can represent the given target. > That will probably be a different environment than the one I may need, > and I think that's fine. I'm really not sure what you're trying to suggest here; maybe you could clarify? If you specify a target (ie a machine type), you get that machine type. If you don't specify a target, then we can't really guess what you were hoping to run and magically pick something that works. The main problem here is that users expect "all the world is a PC" type behaviour, ie they can just provide qemu-system-arm or qemu-system-aarch64 with no command line arguments except a guest kernel (which is half the time something they found under a rock or extracted from some firmware image) or a guest CDROM image and have it boot, because that generally works for x86. It doesn't and can't work for Arm, because of the much greater diversity of machine types and the way that kernels are often only compiled to work on a specific subset of machines. Making the user specify a machine type means they do at least get prompted that the world is more complicated than they think it is and there are decisions that have to be made. In any case even if we did default to "virt" the user still has to specify a CPU type, may well also want to provide a GIC version (gicv3 being better than the default v2), likely more RAM than the very small default, they need to provide all the virtio devices, and so on and so on. So giving them one option they no longer need to specify doesn't really make it any easier IMHO. thanks -- PMM
