On 23/01/18 23:49, David Gibson wrote: > On Tue, Jan 23, 2018 at 01:03:39PM +0100, Andrea Bolognani wrote: >> On Tue, 2018-01-23 at 22:20 +1100, David Gibson wrote: >>>> David, I know you're busy with linux.conf.au, but it would be >>>> really helpful if you could carve out five minutes to look over >>>> Alexey's proposal again, with my reply above in mind, and let us >>>> know whether it looks a reasonable design. Doesn't have to be a >>>> review, just a quick feedback on the high-level idea. >>> >>> It looks ok, I think, but I don't think I'm really the right person to >>> ask. I do wonder if creating a throwaway instance could cause >>> trouble, especially for something like machine that might well have >>> gotten away with having global side-effects in the past. I think we >>> need to talk with someone who knows more about qom and qapi - Markus >>> seems the obvious choice. >> >> Good point. CC'ing Markus to try and grab his attention :) > > It's also occurred to me that making a spapr specific approach to this > might not be quite as horrible as I initially thought. The > capabilities table is global (and immutable) so coding up a > "get-spapr-caps" qapi entry point which encodes the stuff there into > json giving the names and allowed values of each cap would be fairly > straightforward. > > Accurately retreiving default values would be trickier, not sure if > that's important or not.
So, do we want to push it further? Markus has not reacted, added Paolo. http://patchwork.ozlabs.org/patch/863325/ -- Alexey
signature.asc
Description: OpenPGP digital signature
