All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] Our use of #include is undisciplined, and what to do about it
Date: Tue, 15 Mar 2016 13:28:22 +0100	[thread overview]
Message-ID: <87h9g8j57d.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <CAFEAcA8umbSH4FC4gzixJ4MB4=dJXDto-CQmi=SigLCXzk3h_g@mail.gmail.com> (Peter Maydell's message of "Tue, 15 Mar 2016 10:03:29 +0000")

Peter Maydell <peter.maydell@linaro.org> writes:

> On 15 March 2016 at 09:29, Markus Armbruster <armbru@redhat.com> 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 (see "Top
>> scorers").  Some can simply be included less.  Others need to be split,
>> in particular the generated tracers.
>
> But how important is this? Yes, the headers may make up a large
> %-of-total-source-lines, but how much extra actual compile time
> do they add? My off-the-top-of-my-head guess is that most of the
> time will be spent on optimization passes of actual code, and that
> things like structure definitions, typedefs, etc that you find in
> headers aren't going to make a major contribution.

I readily concede that we shouldn't speculate about compile time without
measurements.

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.  I certainly do.  If only the fiddled-with file
got recompiled, I'd happily use them for debugging, and when done post
any new tracepoints I found useful for others to enjoy.

>> Yet another one is reviewing the way we include system and GLib headers.
>
> We must include glib.h from osdep.h because it has compatibility
> fixups (in glib-compat.h) and we need to avoid the risk of a .c
> file including the system header directly without the fixups.

I understand the problem.  Perhaps we can find a less heavy-handed
solution.  Not a priority for me right now.

>> But our root problem is our undisciplined use of #include.  Can we agree
>> on a sane set of rules?  Here's my proposal:
>>
>> 1. Have a carefully curated header that's included everywhere first.  We
>>    got that already thanks to Peter: osdep.h.
>>
>> 2. Headers should normally include everything they need beyond osdep.h.
>>    If exceptions are needed for some reason, they must be documented in
>>    the header.  If all that's needed from a header is typedefs, put
>>    those into qemu/typedefs.h instead of including the header.
>>
>> 3. Cyclic inclusion is forbidden.
>
> I would be happy with these rules; we're a fair way away from them
> though. (Part of my aim with the osdep cleanup was to get to a point
> where it was easier to make header files self-contained without that
> implying every header needing a lot of system #includes.)

Okay, I can try to take us a few more steps in this direction.

  reply	other threads:[~2016-03-15 12:28 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-15  9:29 [Qemu-devel] Our use of #include is undisciplined, and what to do about it Markus Armbruster
2016-03-15  9:40 ` Paolo Bonzini
2016-03-15 12:19   ` Markus Armbruster
2016-03-15 14:51     ` Paolo Bonzini
2016-03-15 10:03 ` Peter Maydell
2016-03-15 12:28   ` Markus Armbruster [this message]
2016-03-15 12:56     ` Peter Maydell
2016-03-15 13:39 ` Stefan Hajnoczi
2016-03-15 13:51   ` Daniel P. Berrange
2016-03-15 13:56   ` Dr. David Alan Gilbert
2016-03-16 18:23     ` Stefan Hajnoczi
2016-03-16 18:27       ` Dr. David Alan Gilbert
2016-03-17 11:25         ` Stefan Hajnoczi
2016-03-17 16:29           ` Dr. David Alan Gilbert
2016-03-17 19:21             ` Paolo Bonzini
2016-03-17 19:43               ` Dr. David Alan Gilbert
2016-03-17 19:58               ` Paolo Bonzini
2016-03-17 20:14               ` Richard Henderson
2016-03-17 20:27                 ` Peter Maydell
2016-03-17 20:29                   ` Richard Henderson
2016-03-17 21:02                     ` Paolo Bonzini
2016-03-17 20:59                 ` Paolo Bonzini
2016-03-17 19:40 ` Richard Henderson
2019-05-27 13:12 ` Markus Armbruster

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=87h9g8j57d.fsf@blackfin.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.