It's been three years, let's examine how things have evolved.
I'm using commit db3d11ee3f0, which is a bit behind current master, just
so I can apply my "[PATCH 0/4] Cleanups around qemu-common.h" cleanly.
Markus Armbruster writes:
[...]
> = The status quo and why I hate it =
>
> I've seen seve
On 17/03/2016 17:29, Dr. David Alan Gilbert wrote:
> OK, so I see TraceEvent has a TraceEventID field; so yes that works easily;
> it turns out to be a little more expensive though since what was a:
>
>trace_events_dstate[id]
>
> is now
>trace_events_dstate[te->id]
That however makes you
On 17/03/2016 21:14, Richard Henderson wrote:
> On 03/17/2016 12:21 PM, Paolo Bonzini wrote:
>> That however makes you waste a lot of cache on trace_events_dstate
>> (commit 585ec72, "trace: track enabled events in a separate array",
>> 2016-02-03).
>
> I must say I'm not really convinced by tha
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> On Wed, Mar 16, 2016 at 06:27:48PM +, Dr. David Alan Gilbert wrote:
> > * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > > On Tue, Mar 15, 2016 at 01:56:47PM +, Dr. David Alan Gilbert wrote:
> > > > > This would put trace_foo() in generated
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 17/03/2016 17:29, Dr. David Alan Gilbert wrote:
> > OK, so I see TraceEvent has a TraceEventID field; so yes that works easily;
> > it turns out to be a little more expensive though since what was a:
> >
> >trace_events_dstate[id]
> >
> > is n
On Wed, Mar 16, 2016 at 06:27:48PM +, Dr. David Alan Gilbert wrote:
> * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > On Tue, Mar 15, 2016 at 01:56:47PM +, Dr. David Alan Gilbert wrote:
> > > > This would put trace_foo() in generated-tracers-virtio-blk.h and
> > > > trace_bar() in genera
On 17/03/2016 21:29, Richard Henderson wrote:
>> > ...Windows is something other than both of those, right?
>> > Or does it use ELF these days?
> PECOFF. But it still supports named sections, so not a deal-breaker.
> We just don't support old a.out systems (e.g. really old OpenBSD).
FWIW Window
On 03/17/2016 01:27 PM, Peter Maydell wrote:
> On 17 March 2016 at 20:14, Richard Henderson wrote:
>> That works for all of the hosts we care about (ELF and MachO).
>
> ...Windows is something other than both of those, right?
> Or does it use ELF these days?
PECOFF. But it still supports named
On 17/03/2016 20:21, Paolo Bonzini wrote:
> On 17/03/2016 17:29, Dr. David Alan Gilbert wrote:
>> OK, so I see TraceEvent has a TraceEventID field; so yes that works easily;
>> it turns out to be a little more expensive though since what was a:
>>
>>trace_events_dstate[id]
>>
>> is now
>>
On 03/17/2016 12:21 PM, Paolo Bonzini wrote:
> That however makes you waste a lot of cache on trace_events_dstate
> (commit 585ec72, "trace: track enabled events in a separate array",
> 2016-02-03).
I must say I'm not really convinced by that patch, since I don't see that
there's much locality bet
On 03/15/2016 02:29 AM, Markus Armbruster wrote:
> Headers can
> be read multiple times, which can only hurt compilation time. You need
> to make an effort to avoid cyclic dependencies and excessive inclusion.
I just want to point out that the preprocessor understands the
#ifndef FOO
#define FOO
On 17 March 2016 at 20:14, Richard Henderson wrote:
> That works for all of the hosts we care about (ELF and MachO).
...Windows is something other than both of those, right?
Or does it use ELF these days?
thanks
-- PMM
On Tue, Mar 15, 2016 at 01:56:47PM +, Dr. David Alan Gilbert wrote:
> > This would put trace_foo() in generated-tracers-virtio-blk.h and
> > trace_bar() in generated-tracers-memory.h. Source files using tracing
> > would need to include headers for relevant sections.
> >
> > This way we can n
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> On Tue, Mar 15, 2016 at 01:56:47PM +, Dr. David Alan Gilbert wrote:
> > > This would put trace_foo() in generated-tracers-virtio-blk.h and
> > > trace_bar() in generated-tracers-memory.h. Source files using tracing
> > > would need to include he
On 15/03/2016 13:19, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 15/03/2016 10:29, Markus Armbruster wrote:
>>> NEED_CPU_H further adds
>>>
>>> include/disas/bfd.h
>>> include/exec/cpu-all.h
>>> include/exec/cpu-common.h
>>> include/exec/cpu-defs.h
>>> include/e
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> On Tue, Mar 15, 2016 at 10:29:06AM +0100, Markus Armbruster wrote:
> > Stefan cc'ed because tracing is part of the problem. Search for
> > "tracers".
>
> Thanks for bringing up the generated tracing headers. David Gilbert and
> I discussed splitti
On Tue, Mar 15, 2016 at 01:39:17PM +, Stefan Hajnoczi wrote:
> On Tue, Mar 15, 2016 at 10:29:06AM +0100, Markus Armbruster wrote:
> > Stefan cc'ed because tracing is part of the problem. Search for
> > "tracers".
>
> Thanks for bringing up the generated tracing headers. David Gilbert and
> I
On Tue, Mar 15, 2016 at 10:29:06AM +0100, Markus Armbruster wrote:
> Stefan cc'ed because tracing is part of the problem. Search for
> "tracers".
Thanks for bringing up the generated tracing headers. David Gilbert and
I discussed splitting them up a few months ago. I'll summarize the
problem an
On 15 March 2016 at 12:28, Markus Armbruster wrote:
> We need to do something about the generated tracers, though. Every time
> you fiddle with a tracepoint, you get to recompile ~900 out of ~4000
> files. I suspect it's only 900 mostly because people avoid tracepoints
> for that exact reason.
Peter Maydell writes:
> On 15 March 2016 at 09:29, Markus Armbruster wrote:
>> = What to do about it =
>>
>> The immediately obvious thing to do is reduce "recompile the world"
>> headers that change frequently. I've started to do that.
>
> This is obviously worthwhile.
>
>> Another one is atta
Paolo Bonzini writes:
> On 15/03/2016 10:29, Markus Armbruster wrote:
>> NEED_CPU_H further adds
>>
>> include/disas/bfd.h
>> include/exec/cpu-all.h
>> include/exec/cpu-common.h
>> include/exec/cpu-defs.h
>> include/exec/exec-all.h
>> include/exec/hwaddr.h
>> include/
On 15 March 2016 at 09:29, Markus Armbruster wrote:
> = What to do about it =
>
> The immediately obvious thing to do is reduce "recompile the world"
> headers that change frequently. I've started to do that.
This is obviously worthwhile.
> Another one is attacking widely included bulky files (
On 15/03/2016 10:29, Markus Armbruster wrote:
> NEED_CPU_H further adds
>
> include/disas/bfd.h
> include/exec/cpu-all.h
> include/exec/cpu-common.h
> include/exec/cpu-defs.h
> include/exec/exec-all.h
> include/exec/hwaddr.h
> include/exec/memattrs.h
> include/exe
This is kind of a meta-cover-letter for the multiple include cleanup
series I hope to post as time permits. The first one will go out later
today.
I'm afraid it's a bit long. You may want to skip ahead to "= What to do
about it =".
Stefan cc'ed because tracing is part of the problem. Search fo
24 matches
Mail list logo
