Hi, > > - Maintainers can deprecate stuffs > > - Orphan code can become Supported > > - Once scheduled for removal, there is no way back > > - 'Unknown' seems pretty similar to 'Orphan'. > > I'm still worried that the supported/unsupported distinction may > cause unnecessary hassle for every downstream distributor of > QEMU. Do we really have a need to differentiate supported vs > unsupported device types at runtime?
How do you suggest to handle cirrus then? Trying to deprecate it outright didn't work very well, kind of understandable given that it has been the default for a long time. So I think we have to mark cirrus as "obsolete", printing a message for the users that they should switch to another display device (stdvga for example), but keep it working for a while. There are also a bunch of devices where I suspect they are not used much if at all. All those isa sound cards for example. Playing old DOS games is pretty much the only use case I can think of. But I'm wondering whenever people actually use qemu for that. There are alternatives which probably handle that use case better, i.e. dosbox. Simliar case is bluetooth emulation. I can't remember having seen any message or patch for years. Tagging such devices as "obsolete", with a message asking people to report their use cases, might help figuring if and why those devices are used in the wild. > I'd prefer to make support/unsupported differentiation to be a > build system feature (e.g. a CONFIG_UNSUPPORTED build-time > option) instead of a QMP/runtime feature. That would be nice too, but I think we need kbuild first, otherwise it'll be pretty messy. cheers, Gerd
