Am 27.01.2012 16:42, schrieb Anthony Liguori: > 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<aligu...@us.ibm.com> >>>>> --- >>>>> 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
Okay, agree. Regards, Andreas > > 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 >> > -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
