Open Stack

On Tue, 18 Aug 2020 10:24:33 +0100
Daniel P. Berrangé <berrange at redhat.com> wrote:

> On Tue, Aug 18, 2020 at 11:06:17AM +0200, Cornelia Huck wrote:
> > On Tue, 18 Aug 2020 09:55:27 +0100
> > Daniel P. Berrangé <berrange at redhat.com> wrote:
> >   
> > > On Tue, Aug 18, 2020 at 11:24:30AM +0800, Jason Wang wrote:  
> > > > Another point, as we discussed in another thread, it's really hard to make
> > > > sure the above API work for all types of devices and frameworks. So having a
> > > > vendor specific API looks much better.    
> > > 
> > > From the POV of userspace mgmt apps doing device compat checking / migration,
> > > we certainly do NOT want to use different vendor specific APIs. We want to
> > > have an API that can be used / controlled in a standard manner across vendors.  
> > 
> > As we certainly will need to have different things to check for
> > different device types and vendor drivers, would it still be fine to
> > have differing (say) attributes, as long as they are presented (and can
> > be discovered) in a standardized way?  
> 
> Yes, the control API and algorithm to deal with the problem needs to
> have standardization, but the data passed in/out of the APIs can vary.
> 
> Essentially the key is that vendors should be able to create devices
> at the kernel, and those devices should "just work" with the existing
> generic userspace migration / compat checking code, without needing
> extra vendor specific logic to be added.
> 
> Note, I'm not saying that the userspace decisions would be perfectly
> optimal based on generic code. They might be making a simplified
> decision that while functionally safe, is not the ideal solution.
> Adding vendor specific code might be able to optimize the userspace
> decisions, but that should be considered just optimization, not a
> core must have for any opertion.

Yes, that sounds reasonable.