[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [RFC] How should QEMU code handle include statements (was: Re: [PATCH 0/5 v2] cpu: make a child of DeviceState)



Am 20.08.2012 13:47, schrieb Igor Mammedov:
On Mon, 20 Aug 2012 06:52:51 +0200
Stefan Weil<sw@xxxxxxxxxxx>  wrote:
I'd prefer if you could keep the following simple pattern:

* Start includes in *.c files with config.h (optionally)
    and qemu-common.h.
Can't agree with you on this. I'd say that every header should be be self
sufficient, include other headers if it uses types from them and NOT depend on
the position where it's included, it should provide all its own deps.
* Don't include standard include files which are already
    included in qemu-common.h
Probably initially qemu-common.h was intended to simplify inclusion
of standard headers and glue stuff in multi-os build environment. but it seems
to be become misused. It includes now a lot of stuff that is not common to
every file it's included in.
Perhaps we should split out of it std includes and glue layer into something
like std/host-common.h and case on case basis move out other type
definitions that are not common into there appropriate places. Like with
qemu_irq.


There are several possible strategies regarding include statements:

1. Each header file which represents some public interface must include
   any header file which it depends on, so applications which include
   xxx.h can rely on the fact that they won't need anything else to
   compile xxx.h.

   To minimize dependencies, this rule can be extended: each header
   file must not include unneeded header files.

   Usually header files in /usr/include are built according to these rules.

2. There is one header file (or a small set of header files) which includes
   a basic set of features which normal code needs. Any C code file starts
   by including this header file.

   Other header files can rely on the fact that the basic set of features
   are already available.

3. In a modification of (2), each header file can include the basic
   header file(s).

4. The status quo of QEMU is a wild mixture of those strategies.

IMHO, there should be a consensus about the strategy which is used
for QEMU code.

While I personally prefer (1) and used it for my first contributions,
QEMU introduced qemu-common.h. I had the impression that from then on
QEMU preferred strategy (2). Obviously not everybody shares that
impression.

Which strategy / rule do we want to use for QEMU code?

Regards,

Stefan Weil


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.