Am 27.03.2017 um 10:06 hat Thomas Huth geschrieben: > On 24.03.2017 23:10, John Snow wrote: > > On 03/08/2017 03:26 AM, Thomas Huth wrote: > >> > >> Hi everybody, > >> > >> what will be the next version of QEMU after 2.9? Will we go for a 2.10 > >> (as I've seen it mentioned a couple of times on the mailing list > >> already), or do we dare to switch to 3.0 instead? > >> > >> I personally dislike two-digit minor version numbers like 2.10 since the > >> non-experienced users sometimes mix it up with 2.1 ... and there have > >> been a couple of new cool features in the past releases that would > >> justify a 3.0 now, too, I think. > >> > >> But anyway, the more important thing that keeps me concerned is: Someone > >> once told me that we should get rid of old parameters and interfaces > >> (like HMP commands) primarily only when we're changing to a new major > >> version number. As you all know, QEMU has a lot of legacy options, which > >> are likely rather confusing than helpful for the new users nowadays, > >> e.g. things like the "-net channel" option (which is fortunately even > >> hardly documented), but maybe also even the whole vlan/hub concept in > >> the net code, or legacy parameters like "-usbdevice". If we switch to > >> version 3.0, could we agree to remove at least some of them? > >> > >> Thomas > >> > > > > As others have stated, we need a few releases to deprecate things first. > > > > Maybe we should develop a serious plan to develop some of our legacy > > interfaces first. > > > > Maybe 2.10 can introduce a list of things we want to deprecate, > > 2.11 can be the transition release, > > and then 3.0 can cut the cord and free of us our terrible burden? > > > > I have a list of things I want to axe... > > I've started a Wiki page with such a list here: > > http://wiki.qemu-project.org/Features/LegacyRemoval > > Feel free to amend!
I propose deprecating -drive (in favour of -blockdev/-device) and added it to the list. Similar to -net, we still need to check that all block devices created internally by individual machines can still be configured. As far as I know, this is already true for the PC, not sure about other machines. But maybe we really should treat that as a problem of qdev/QOM, which should provide a mechanism to set options for automatically created devices rather than relying on subsystem-specific ways (like -net or -drive) to bypass the normal qdev configuration. Kevin
