On 12/4/18 7:06 PM, Eduardo Habkost wrote: > On Mon, Dec 03, 2018 at 03:09:14PM +0100, Luc Michel wrote: >> >> >> On 12/3/18 12:23 PM, Peter Maydell wrote: >>> On Mon, 3 Dec 2018 at 11:21, Luc Michel <luc.mic...@greensocs.com> wrote: >>>> >>>> On 11/30/18 5:52 PM, Peter Maydell wrote: >>>>> Luc: what are the requirements on boards using CPU cluster >>>>> objects? I assume these are both OK: >>>>> * does not use cluster objects at all >>>>> (the gdbstub puts all the CPUs in one process?) >>>> Yes, when no clusters are found, a process with PID 1 is created and >>>> used for all CPUs. >>>>> * all CPUs created are in some CPU cluster >>>>> (the gdbstub uses one process per CPU cluster) >>>>> but what about >>>>> * some CPUs are created in a CPU cluster, but some >>>>> are "loose", not in any cluster at all> ? >>>>> Is that just invalid, or do the "loose" CPUs end up in >>>>> a default cluster (gdbstub process), or do they get >>>>> one cluster each? >>>> Currently this is valid and the "loose" CPUs end up in the first >>>> available process (which will be PID 1 if we are in your first case, >>>> i.e. no clusters in the machine). >>> >>> So if there are some defined clusters 1 and 2, and some >>> loose CPUs, the clusters get PID 1 and PID 2, and the >>> loose CPUs end up in PID 3? That seems reasonable. >> No sorry I was not clear, the loose CPUs would end up on PID 1 in that case. >> >> The current behaviour is as follows: >> During gdb stub initialization: >> - A process is created per cluster. >> - If no cluster are found, an unique process is created with PID 1 >> >> When trying to find a CPU PID: >> - If it is attached to a cluster, return the associated process, >> - If it is loose, return the first available process. > > The behavior described by Peter would be more reasonable to me. > Otherwise what was just an accident (getting the CPU assigned to > the first process) will become expected behavior of the API, and > it will be hard to change it later. Make sense, I'll change that to adopt the behaviour described by Peter.
> > In either case, I'm still missing a clear description of what a > cluster is supposed to represent, exactly (see my previous reply > on this thread). I'll add a description in the next re-roll, using the Peter's one as a starting point. Thanks. -- Luc
