Alexey Kardashevskiy <[email protected]> writes: > 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/
I now have. Sorry for the long delay.
