qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 04/28] qom: add the base Object class (v2)


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 04/28] qom: add the base Object class (v2)
Date: Fri, 27 Jan 2012 09:42:03 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

On 01/27/2012 09:05 AM, Andreas Färber wrote:
Am 25.01.2012 22:37, schrieb Anthony Liguori:
On 01/25/2012 03:30 PM, Andreas Färber wrote:
Am 24.01.2012 20:32, schrieb Anthony Liguori:
This class provides the main building block for QEMU Object Model and is
extensively documented in the header file.  It is largely inspired by
GObject.

Signed-off-by: Anthony Liguori<address@hidden>
---
v1 ->   v2
   - remove printf() in type registration
   - fix typo in comment (Paolo)
   - make Interface private
   - move object into a new directory and move header into include/qemu/

Some of us had expressed concerns over introducing include/. Any
particular reason you're doing it still?

Because it's a great idea and I thought everyone loved it?

Can you point me to the concerns raised, I'll go back and look.  I
didn't think it was contentious...

Can't find it right now (stupid search keyword!)

No problem.

but I remember having a
discussion around whether these are actually "public" APIs because to
date we have always claimed that all APIs are internal and no guarantees
are made. IMO moving headers to an include/ dir marks a change of that
policy because header in include/ usually get installed alongside a
library so if we do it we should do it conciously.

Thing is, headers that are private to one part of code are public to
another. It's not black and white. E.g., hw ->  IDE ->  AHCI ->  ICH9.
Whenever there's multiple subclasses code needs to be shared; it
shouldn't usually be poked at from the outside though in favor of
qdev/QOM properties.

Personally, I find it more handy to find pci_dec.c and pci_dec.h in the
same directory in Nautilus/gedit/whatever (but bad example because I'm
working on making that header go away). On the other hand compared to
like r955 we have seen a huge inflation in hw/ files.
I can live with it either way, and as Paolo says, it can easily be
changed later with git-mv. And #include "qemu/foo.h" sounds fair.

When I think of include/, I think of "internally public" headers. IOW, things that are meant to be shared in other parts of QEMU. For instance, something like qemu-queue.h.

In fact, there are 25 header files in $SRCDIR that are in the form qemu-$file.h. They could (and should) probably be moved to include/qemu/$file.h

As we introduce more directory structure, having a single include directory will be very handy. For instance, pci_dec.c may move to drivers/ppc/pci_dec.c. But having pci_dec.h in include/qemu means that we don't have to worry about very long #include paths.

Regards,

Anthony Liguori


For these new "public" headers I'd be interested in finding a solution
where we can all easily collaborate on the documentation though. Right
now we need to trust you to get the markup right.

Andreas

To summarize my rationale for it:

  1) It avoids all of the non-sense with conflicting system headers
(because we -Iinclude and the headers live in include/qemu)

  2) It establishes what are public functions for use in other parts of
qemu vs. private headers (which we currently use based on ad-hoc naming
schemes like block_int.h).

  3) I think the kernel serves as an existence proof that this method to
manage headers works really well in practice.

Regards,

Anthony Liguori





reply via email to

[Prev in Thread] Current Thread [Next in Thread]