From: Markus Armbruster <armbru@redhat.com>
To: Josh DuBois <josh@joshdubois.com>
Cc: qemu-trivial@nongnu.org, Stefan Hajnoczi <stefanha@gmail.com>,
Josh DuBois <duboisj@gmail.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH] trace/simple: Allow enabling simple traces from command line
Date: Wed, 05 Aug 2020 06:38:48 +0200 [thread overview]
Message-ID: <87h7th7llz.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <A86BEB45-4022-4D7C-936C-5CDCC580EBF8@joshdubois.com> (Josh DuBois's message of "Tue, 4 Aug 2020 12:41:12 -0500")
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!
prev parent reply other threads:[~2020-08-05 4:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 5:33 [PATCH] trace/simple: Allow enabling simple traces from command line Josh DuBois
2020-07-29 13:05 ` Stefan Hajnoczi
2020-07-30 22:50 ` Josh DuBois
2020-08-03 9:08 ` Markus Armbruster
2020-08-04 17:41 ` Josh DuBois
2020-08-05 4:38 ` Markus Armbruster [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h7th7llz.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=duboisj@gmail.com \
--cc=josh@joshdubois.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).