Gerd Hoffmann <kra...@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.
