On Tue, 18 Aug 2020 10:24:33 +0100 Daniel P. Berrangé <berra...@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é <berra...@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.
