All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corneliu ZUZU <czuzu@bitdefender.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Razvan Cojocaru <rcojocaru@bitdefender.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel@lists.xen.org, Julien Grall <julien.grall@arm.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	Tamas K Lengyel <tamas@tklengyel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter
Date: Fri, 17 Jun 2016 15:13:57 +0300	[thread overview]
Message-ID: <b8b221c2-361d-707a-a6b4-3f70e8d796ae@bitdefender.com> (raw)
In-Reply-To: <5763FADC02000078000F61F5@prv-mh.provo.novell.com>

On 6/17/2016 2:27 PM, Jan Beulich wrote:
>>>> On 17.06.16 at 13:13, <czuzu@bitdefender.com> wrote:
>> On 6/17/2016 10:17 AM, Jan Beulich wrote:
>>> (And to be clear, I much appreciate any form of reduction of the
>>> sometimes extremely long lists of #include-s, just not [apparently
>>> or really] randomly mixed with other, substantial changes. That's
>>> namely because it's not clear whether source files should explicitly
>>> include everything they need, or instead be allowed to rely on
>>> headers they include to include further headers they also
>>> _explicitly_ rely on.
>> Personally I prefer the former since I think it also cuts down
>> compilation time.
>> Having header H include every header Ni needed by source S makes H
>> unnecessarily bulky at compilation time for other sources <> S that
>> don't need headers Ni but which depend on H nonetheless.
> I nowhere said every _header_ should include everything any of
> its _consumers_ would require. My point was solely about source
> files. For example, if S depends on both H1 and H2, and H2
> already includes H1, whether S then needs to just include H2, or
> should also explicitly include H1 (such that S doesn't need changing
> when the inclusion of H1 by H2 goes away).
>
> Jan
>
>

Ah, ok got it.
I restate my view of treating these "issues" with automation tools 
rather than leaving the programmer to do primitive work that he 
shouldn't be required to do with a nowadays programming language.
Clang for example offers a powerful parsing library (can parse GCC too) 
with python bindings, it would be nice to take more advantage of that.

Corneliu.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-06-17 12:13 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-16 14:04 [PATCH 0/7] vm-event: Implement ARM support for control-register writes Corneliu ZUZU
2016-06-16 14:06 ` [PATCH 1/7] minor (formatting) fixes Corneliu ZUZU
2016-06-16 14:24   ` Jan Beulich
2016-06-16 19:19     ` Corneliu ZUZU
2016-06-17  7:06       ` Jan Beulich
2016-06-17 10:46         ` Corneliu ZUZU
2016-06-16 16:02   ` Tamas K Lengyel
2016-06-17  8:33     ` Corneliu ZUZU
2016-06-17  8:36       ` Razvan Cojocaru
2016-06-17  9:29         ` Andrew Cooper
2016-06-17  9:35           ` Jan Beulich
2016-06-17  9:33         ` Jan Beulich
2016-06-17  9:36           ` Razvan Cojocaru
2016-06-17  9:40             ` Jan Beulich
2016-06-17  9:42               ` Razvan Cojocaru
2016-06-17 19:05           ` Tamas K Lengyel
2016-06-16 14:07 ` [PATCH 2/7] vm-event: VM_EVENT_FLAG_DENY requires VM_EVENT_FLAG_VCPU_PAUSED Corneliu ZUZU
2016-06-16 16:11   ` Tamas K Lengyel
2016-06-17  8:43     ` Corneliu ZUZU
2016-06-21 11:26     ` Corneliu ZUZU
2016-06-21 15:09       ` Tamas K Lengyel
2016-06-22  8:34         ` Corneliu ZUZU
2016-06-16 14:08 ` [PATCH 3/7] vm-event: introduce vm_event_vcpu_enter Corneliu ZUZU
2016-06-16 14:51   ` Jan Beulich
2016-06-16 20:10     ` Corneliu ZUZU
2016-06-16 20:33       ` Razvan Cojocaru
2016-06-17 10:41         ` Corneliu ZUZU
2016-06-17  7:17       ` Jan Beulich
2016-06-17 11:13         ` Corneliu ZUZU
2016-06-17 11:27           ` Jan Beulich
2016-06-17 12:13             ` Corneliu ZUZU [this message]
2016-06-16 16:17   ` Tamas K Lengyel
2016-06-17  9:19     ` Corneliu ZUZU
2016-06-17  8:55   ` Julien Grall
2016-06-17 11:40     ` Corneliu ZUZU
2016-06-17 13:22       ` Julien Grall
2016-06-16 14:09 ` [PATCH 4/7] vm-event/x86: use vm_event_vcpu_enter properly Corneliu ZUZU
2016-06-16 15:00   ` Jan Beulich
2016-06-16 20:20     ` Corneliu ZUZU
2016-06-17  7:20       ` Jan Beulich
2016-06-17 11:23         ` Corneliu ZUZU
2016-06-16 16:27   ` Tamas K Lengyel
2016-06-17  9:24     ` Corneliu ZUZU
2016-06-16 14:10 ` [PATCH 5/7] x86: replace monitor_write_data.do_write with enum Corneliu ZUZU
2016-06-16 14:12 ` [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr Corneliu ZUZU
2016-06-16 15:16   ` Jan Beulich
2016-06-17  8:25     ` Corneliu ZUZU
2016-06-17  8:38       ` Jan Beulich
2016-06-17 11:31         ` Corneliu ZUZU
2016-06-21  7:08       ` Corneliu ZUZU
2016-06-21  7:20         ` Jan Beulich
2016-06-21 15:22           ` Tamas K Lengyel
2016-06-22  6:33             ` Jan Beulich
2016-06-16 16:55   ` Tamas K Lengyel
2016-06-17 10:37     ` Corneliu ZUZU
2016-06-16 14:13 ` [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events Corneliu ZUZU
2016-06-16 14:26   ` Julien Grall
2016-06-16 19:24     ` Corneliu ZUZU
2016-06-16 21:28       ` Julien Grall
2016-06-17 11:46         ` Corneliu ZUZU
2016-06-16 16:49   ` Julien Grall
2016-06-17 10:36     ` Corneliu ZUZU
2016-06-17 13:18       ` Julien Grall
2016-06-22 16:35       ` Corneliu ZUZU
2016-06-22 17:17         ` Julien Grall
2016-06-22 18:39           ` Corneliu ZUZU
2016-06-22 19:37             ` Corneliu ZUZU
2016-06-22 19:41               ` Julien Grall
2016-06-23  5:31                 ` Corneliu ZUZU
2016-06-23  5:49                   ` Corneliu ZUZU
2016-06-23 11:11                     ` Julien Grall
2016-06-24  9:32                       ` Corneliu ZUZU
2016-06-23 11:00           ` Julien Grall

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=b8b221c2-361d-707a-a6b4-3f70e8d796ae@bitdefender.com \
    --to=czuzu@bitdefender.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=julien.grall@arm.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=paul.durrant@citrix.com \
    --cc=rcojocaru@bitdefender.com \
    --cc=sstabellini@kernel.org \
    --cc=tamas@tklengyel.com \
    --cc=xen-devel@lists.xen.org \
    /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.