On Mon, 7 Jul 2025 at 15:03, Stefan Hajnoczi <stefa...@redhat.com> wrote: > > On Fri, Jul 04, 2025 at 02:14:35PM +0100, Peter Maydell wrote: > > On Mon, 30 Jun 2025 at 17:53, Pierrick Bouvier > > <pierrick.bouv...@linaro.org> wrote: > > > > > > On 6/30/25 6:09 AM, Philippe Mathieu-Daudé wrote: > > > > It is useful to compare PSCI calls of the same guest running > > > > under TCG or HVF. > > > > > > > > Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org> > > > > --- > > > > target/arm/hvf/hvf.c | 3 ++- > > > > target/arm/tcg/psci.c | 3 +++ > > > > target/arm/trace-events | 3 +++ > > > > 3 files changed, 8 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c > > > > index 7a99118c8c2..6309c5b872e 100644 > > > > --- a/target/arm/hvf/hvf.c > > > > +++ b/target/arm/hvf/hvf.c > > > > @@ -34,6 +34,7 @@ > > > > #include "target/arm/multiprocessing.h" > > > > #include "target/arm/gtimer.h" > > > > #include "trace.h" > > > > +#include "../trace.h" > > > > > > > Just a nit, using 'target/arm/trace.h' might be more readable than > > > '../trace.h'. > > > > Mmm. docs/devel/tracing.rst rather discourages this: > > > > # While it is possible to include a trace.h file from outside a source > > file's own > > # sub-directory, this is discouraged in general. It is strongly preferred > > that > > # all events be declared directly in the sub-directory that uses them. The > > only > > # exception is where there are some shared trace events defined in the top > > level > > # directory trace-events file. > > > > I don't know if we want to loosen that to permit events > > that are shared between multiple subdirs (cc'ing the > > trace subsystem maintainers for their view). > > Code is generated from the trace-events files and my main concern is > that the build dependencies on the generated code may not be obvious if > a trace event from somewhere far away in the source tree hierarchy is > used. You might hit linker errors because the .o files needed for the > trace events are not being linked in. > > I would try to stick with what's described in tracing.rst to avoid > difficulties now or in the future.
So how should we deal with "two different source files in different subdirectories both want to emit trace event X" ? Creating a utility function that can live in the parent dir just to wrap the trace event seems a bit inefficient. I agree that using a trace event from a long way away across the source tree is probably a bad idea, but "immediate parent directory" doesn't seem too likely to cause issues ? -- PMM
