Hi,
> > This does seem quite aggressive because there may be cases when users
> > explicitly want to use old devices. Maybe there is need for a third
> > state (better_alternatives?) so we can steer users away from old command
> > lines they may have picked up from the web to the modern alternative?
>
> We've got 2 flags proposed in patch 1 - "deprecated" and "not_secure" -
> which we formally expose to mgmt apps/users. Both of these are actionable
> in an unambiguous way. An application can query this info, and can also
> tell QEMU to enforce policy on this. Both are good.
Well, given that people apparently don't want actually delete stuff
I'm not sure the 'deprecated' flag actually makes sense.
> The "better alternatives" conceptable, however, is an inherantly fuzzy
> concept, because "better" is very much a use-case depedent / eye of the
> beholder concept.
Well. I think the use cases can be grouped into two cases:
(1) Operating system museum. People using qemu qemu to keep their
beloved (historical) OS alive on modern hardware.
(2) Virtualization. Run your production workload in VMs.
For (1) "better alternatives" doesn't make sense because you have to
consider what your (old) guest OS supports.
For (2) I think it does make sense. I'd be conservative here and would
define possible production workloads as "OS which is still supported
with security updates". Hardware old enough to be supported by all
production workloads (which should roughly being 10-15 years in the
market) can go into the "better alternative" bucket. Examples:
- xhci is old enough and can replace ohci/uhci/ehci.
- intel-hda is old enough and can replace ac97/es1370/sb/...
- sata is old enough and can replace ide.
- nvme isn't old enough yet I'd say (also no cdrom support so it
can't fully replace ide/sata).
- q35 is old enough and can replace pc.
> This would makes it difficult/impractical for an application to take
> action based on such a "better-alternatives' schema marker. It would
> imply the application has to understands the better alternatives ahead
> of time, as well as understanding the end users' intent and that's not
> really viable.
Well, with the conservative classification it should be possible to
simply apply it universally. Throw warnings or errors in case a device
with a "better-alternative" tag is used. Or build qemu without these
devices. Or move these devices to a sub-rpm (if modularized), so they
are not present by default but can be installed for the (1) use cases.
take care,
Gerd
