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@xxxxxxxxxx> 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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
