Hide Forgot
A rebase can easily introduce unwanted changes to stable interfaces. To avoid that, we need to find and review interface differences. Machine type and device configuration is one such interface. We need to review: - Semantics of machine types Machine types set configuration variables, including qdev compat_props. Any new variables? Lost ones? Replaced ones? Changed values? This is entirely manual. - Devices Any new devices? Lost ones? Unwanted devices need to be cut or made inaccessible. Finding available devices manually is too error-prone. Use introspection. In modern QEMU: qom-list-types. - Device properties Any new devices? Lost ones? Finding available properties manually even more error-prone than devices. In modern QEMU: device-list-properties. Note that it doesn't work for some devices. - Changed property types This should be rare. The type returned by device-list-properties should do. - Changed property default values We lack a way to introspect the default value. Long term, upstream introspection should be extended to cover this. Short term, we may have to settle for a downstream hack. Note that default values may depend on the machine type. The checking is the same for major and minor releases. The difference is in the kind of changes we accept. The review should produce a document detailing the changes. For each change, explain whether its wanted or not, and why. For unwanted changes, point to a BZ. We need tooling to automate gathering the data to review.
Currently, there's rebase verification checklist for this. We need to assing machine type owner for each architecture that will be responsible (leader) for post-rebase testing and implementation (new machine types has own bz).