On Fri, Oct 05, 2018 at 03:50:01PM +0200, Philippe Mathieu-Daudé wrote: > On 04/10/2018 23:53, Eduardo Habkost wrote: > > On Thu, Oct 04, 2018 at 09:01:09PM +0100, Peter Maydell wrote: > >> On 4 October 2018 at 20:52, Eduardo Habkost <ehabk...@redhat.com> wrote: > >>> Changing the object hierarchy based on GDB groups doesn't seem > >>> right, but I don't think it would be a big deal if we have the > >>> board code explicitly telling the GDB code how to group the CPUs. > >>> > >>> If you really want to do it implicitly, would it work if you > >>> simply group the CPUs based on object_get_canonical_path()? > >>> > >>> If a more explicit GDB grouping API is acceptable, what about > >>> just adding a INTERFACE_GDB_GROUP interface name to (existing) > >>> container objects that we expect to become GDB groups? > >>> > >>> I'm not sure which way is better. I'm a bit worried that making > >>> things too implicit could easily break (e.g. if somebody changes > >>> the CPU QOM hierarchy in the future for unrelated reasons). > >> > >> I don't want things implicit. I just don't want the explicitness > >> to be "this is all about GDB", because it isn't. I want us > >> to explicitly say "these 4 CPUs are in one cluster" (or > >> whatever term we use), because that affects more than merely GDB. > > > > We already have a way to say "these 4 CPUs are in one cluster", > > don't we? That's the QOM hierarchy. > > > > My question is if "the CPUs are in one cluster" should implicitly > > mean "the CPUs are in one GDB group". > > > > What about having the container implement INTERFACE_CPU_CLUSTER? > > Or even cleaner, add a TYPE_CPU_CLUSTER which is just a container for > TYPE_CPU[*]?
Sounds good to me. An interface sounds more flexible, to avoid clashing with existing type hierarchies for nodes/sockets/cores/etc. But first of all, I think we need a good definition of what exactly is a cluster, and what is the purpose of this abstraction. If we end up with a new abstraction that is only going to used by GDB code and nothing else, I don't see the point of pretending it is not a GDB-specific abstraction. -- Eduardo
