Re: [PATCH v3 0/4] allow to deprecate objects and devices

[Markus Armbruster <armbru@redhat.com>]

Gerd Hoffmann <kraxel@redhat.com> writes:

> Put some infrastructure in place to allow tagging objects (including
> devices) as deprected.  Use it to mark the ohci pci host adapter and
> the usb hub as deprecated.

I can see usb-hub [PATCH 2], but not "ohci pci host adapter".  Peeking
at the change log below... dropped in v2?

> v3:
>  - switch to two properties: 'deprecated' and 'not secure' flags.
>  - add rfc patch implementing policies for devices with flags.
>
> v2:
>  - pick up reviews.
>  - drop ohci patch.
>  - add cirrus vga patch.
>
> Gerd Hoffmann (4):
>   qom: allow to mark objects as deprecated or not secure.
>   usb/hub: mark as deprecated
>   vga/cirrus: mark as not secure

This part isn't mentioned in the cover letter.

>   qdev: add device policy [RfC]

There's overlap with QAPI special feature 'deprecated'.

QMP command object_add has argument @qom-type, which is an enumeration
of (user-creatable) object types.  The proper way to mark one of these
deprecated is to tack feature 'deprecated' to it.  It is then subject to
policy set with -compat deprecated-input=XXX, and is visible in
query-qmp-schema.  Modern management applications should already know
how to deal with it there.

This is definitely how we should deprecate user-creatable objects.
Adding a second way to do it seems undesirable to me.

Trouble is QMP command device_add still mostly bypasses QAPI.  Its
argument @driver is a string.

QAPIfying device_add properly has been on our (unwritten) wishlist since
forever.  Kevin (cc'ed) explored it some not too long ago.

I figure you want the means to deprecate devices now rather than after
we figure out how to QAPIfy device_add.  That's fair.

I think we should limit this series just to devices.  It'll become
redundant if we ever succeed at QAPIfying device_add.  No need to worry
about that now.