On 12/2/20 8:47 PM, Laine Stump wrote:
So, that's my piece to speak. I'm looking for opinions and ideas on a
few different fronts:
1) Does this generally sound like a good direction? Or is there
something I'm ignoring that renders my points moot?
Yes, it sounds good. A few years back I wanted to adapt netcf for my
distro, but never gotten around it, since there was no real consumer,
only my motivation to build libvirt with everything possible.
2) If we are going to do it, how should we proceed?
We obviously can't simply *remove* the virInterface API from libvirt
(since that would destroy backward compatibility guarantees), but could
immediately begin logging some sort of "this API is deprecated" message
when any of the functions are called, and then in a later release change
the APIs to return an error (while simultaneously removing netcf from
the build and dependency lists). At the same time, we would need to
decide if the "interface status" functionality needs to be maintained
within appropriate virInterface*() APIs, reproduced in
virNodeDeviceGetXMLDesc(), or just dropped altogether.
What we usually do is we remove the driver implementation and let public
API report unsupported error (since driver->XXX callback is going to be
NULL), for instance: 464a41bc0de. Before that, we reported a deprecated
error (6f532d7ffc3 and 5cc402a9b4c).
This was paired with documentation:
a8073797ce174f6eaa622104e4fd33ee88cb6fad
Michal
