Hi,
> > Upstream QEMU's scope is to emulate pretty much arbitrary hardware that
> > may have existed at any point in time. Emulating Cirrus is very much
> > in scope upstream, and even if there are other better VGA devices, that
> > doesn't make emulation of Cirrus redundant.
> >
> > Downstream is a different matter - if a downstream vendor wants to be
> > opinionated and limit the scope of devices they ship to customers, it
> > is totally valid to cull Cirrus.
>
> Few years ago I suggested qemu_security_policy_taint() "which allows
> unsafe (read "not very maintained") code to 'taint' QEMU security
> policy." (Gerd FYI):
> https://lore.kernel.org/qemu-devel/20210908232024.2399215-1-phi...@redhat.com/
>
> Upstream we could add a boolean in DeviceClass about device security
> status / maintenance (or enum or bitfield); then downstreams could
> use it to be sure unsafe devices aren't linked in.
Yes, I think it makes sense to maintain that information upstream. It
is useful information to have. Even if upstream isn't going to enforce
something qemu could print useful hints.
So, the question is whenever we want go for a simple bool, or go for a
bitfield giving more detailed information. Bits I think could be
useful:
(1) OBJECT_STATUS_DEPRECATED
Stuff we actually want remove. Very few cases, maybe usb-hub.
(2) OBJECT_STATUS_UNSAFE
"not very maintained". Probably need a better name for this.
(3) OBJECT_STATUS_OUTDATED
Old device where newer / better alternatives exist.
Looking at the USB host adapters I'd attach 2+3 to ohci and 3 to uhci
and ehci. In general there is a lot of overlap for (2) + (3) though.
We might also have recommendation bits such as:
(4) OBJECT_STATUS_VIRTUALIZATON
Devices recommended for virtualization use cases
(all virtio, xhci, ...).
> > IOW, I think device deprecation *framework* is relevant to include
> > upstream, but most actual usage of it will be downstream.
When doing it at ObjectClass not DeviceClass level we get introspection
support for (almost) free, so I'd do it for ObjectClass even if the vast
majority of users will be devices.
> > Upstream might use *object* deprecation, if we replace an backend
> > implementation with a different one.
Sounds like having OBJECT_STATUS_DEPRECATED makes sense even if we don't
have any device actually using that.
take care,
Gerd
