Josh DuBois <j...@joshdubois.com> writes: > Well, this is a bit embarrassing. The patch below simply > re-introduced the bug which the Fixes: line was trying to fix in the > first place. > > I.e, : > > - with my patch (just committed as > 1b7157be3a8c4300fc8044d40f4b2e64a152a1b4) applied, a QEMU built with > simple tracing will always produce a trace-<pid> file, regardless of > whether traces were asked for. > > - after db25d56c014aa1a96319c663e0a60346a223b31e, which my patch was > supposed to "fix," QEMU will not produce a trace file unless asked, I > believe, via the monitor. Enabling traces is, near as I can tell, > simply impossible via the command-line in that case. > > - 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. > I'm sorry for the mess. Having stepped in it already, I'm open to > trying to track it down and fix it properly. I imagine perhaps few > people truly care, since traces require a special build and are > probably only being done by developers anyway. (And the original > message for db25d56c014aa1a96319c663e0a60346a223b31e said it had been > "broken" for an unknown period of time). > > I'm brand new around here so I'll leave it to others whether it's > better to revert and have traces impossible to enable from the cli (as > I say, I think they're only possible from the monitor prior to my > "fix" ) or to leave it be. > > If I resubmit, I'll try to test a little more next time. I just > wanted my traces to work. ;) 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.
