[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] trace/simple: Allow enabling simple traces from command line
From: |
Markus Armbruster |
Subject: |
Re: [PATCH] trace/simple: Allow enabling simple traces from command line |
Date: |
Wed, 05 Aug 2020 06:38:48 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Josh DuBois <josh@joshdubois.com> writes:
> On Aug 3, 2020, at 4:08 AM, Markus Armbruster <armbru@redhat.com> wrote:
>>
>>>
>>> - prior to db25d56c014aa1a96319c663e0a60346a223b31e, just like today,
>>> QEMU built with simple tracing will always produce a trace-<pid> file,
>>> regardless of whether the user asks for traces at runtime.
>>
>> When you send a patch with a Fixes: tag, consider cc'ing people involved
>> in the commit being fixed. I might have spotted the regression.
>
> Sure, this makes sense.
>
>> I missed the CLI issue. I just wanted my directories not littered with
>> trace files ;)
>>
>> Stefan, what shall we do for 5.1?
>>
>> If we keep littering, the annoyance will make me drop the trace backend
>> "simple" from my build tests. I might even remember to put it back when
>> the fix arrives.
>
> I haven't seen another response, but I just noticed a 'last call' for 5.1.
> If this means something is going to get excluded from regular build tests,
> that seems important - I for one have no objection to simply reverting this -
> 1b7157be3a8c4300fc8044d40f4b2e64a152a1b4 <-- my "fix."
These are just my local build test. Our CI is not affected.
Reverting is up to Stefan.
> I will try to send a better fix along sometime soonish, but I probably won't
> get to that before 5.1. If the nuisance of the trace-<pid> files is causing
> real-world problems for someone actually doing regular development, that
> seems more important than the command line issue, to me. Just my $0.02.
>
> Cheers, and sorry if your build dirs do end up littered again.
Sorry for breaking your use case, and looking forward to your fix for
your fix!