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.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
