[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DRAFT PATCH 000/143] Meson integration for 5.2

From: Philippe Mathieu-Daudé
Subject: Re: [DRAFT PATCH 000/143] Meson integration for 5.2
Date: Mon, 10 Aug 2020 12:32:27 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 8/7/20 5:58 PM, Daniel P. Berrangé wrote:
> On Fri, Aug 07, 2020 at 05:14:06PM +0200, Paolo Bonzini wrote:
>> That one exception, the one thing that disappoints me of the whole
>> conversion, is the trace.h files.  The current solution is one of the
>> first parts I did of the conversion and I have never touched it since; I
>> think it can be improved (I can even think of two ways to do it), but I
>> don't really have the time to do it now.  But even that bit is just
>> ugly, not unmaintainable, and I really see nothing in the conversion
>> that is a step back for QEMU's long term maintainability and our ability
>> to develop new features.
> I was never entirely happy with the trace.h stuff even in "make".
> Trying to maintain the "trace.h" name for every generated header
> was probably a mistake in retrospect. it caused me so much pain
> trying to get the "make" rules correct so that we resolved the
> right trace.h in each case. I was deperately trying to avoid
> updating the #include lines, but I'm not sure it was worth
> it in the end. Would have been easier to just generate a unique
> header file name for each dir and update the #includes.

Never too late. Having unique trace headers would allow us to reuse
trace functions in different modules.

- hexdump()
- cases where multi-devices not well split in subsystem parts
  . xen out of i386
  . net could reuse mdio
  . rocker out of net
  . can out of net
  . reuse semihosting traces in target/
- cases with buses where the device is target-specific

> Regards,
> Daniel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]