This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qe

To: Gerd Hoffmann <kraxel@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qemu
From: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Date: Thu, 7 Aug 2008 17:48:43 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Markus Armbruster <armbru@xxxxxxxxxx>, Anthony Liguori <anthony@xxxxxxxxxxxxx>, qemu-devel@xxxxxxxxxx
Delivery-date: Thu, 07 Aug 2008 09:49:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <489B2023.8030101@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Mail-followup-to: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>, Gerd Hoffmann <kraxel@xxxxxxxxxx>, Markus Armbruster <armbru@xxxxxxxxxx>, Anthony Liguori <anthony@xxxxxxxxxxxxx>, qemu-devel@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
References: <4899AD19.8060606@xxxxxxxxxx> <20080806140132.GL4448@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4899B06F.2090101@xxxxxxxxxx> <20080806142526.GN4448@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080806221047.GE4486@implementation> <489AA532.7040006@xxxxxxxxxx> <20080807105352.GC6604@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <489AE6E2.2040500@xxxxxxxxxx> <20080807125402.GF6604@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <489B2023.8030101@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.12-2006-07-14
Gerd Hoffmann, le Thu 07 Aug 2008 18:17:39 +0200, a écrit :
> Samuel Thibault wrote:
> > Gerd Hoffmann, le Thu 07 Aug 2008 14:13:22 +0200, a écrit :
> >>> Any reason for the renames, though? (they tend to bother developpers who
> >>> have to change their habits, so we can not do that without a reason)
> >> Get consistent naming (all xen stuff in hw/ is prefixed with xen-).
> > 
> > Err, no, in xen they are all prefixed with xen_ (except xenfb).
> Uhm, No.

Right, there is xenstore as well.

> ~/xen/qemu-dm# grep ^OBJS xen-hooks.mak
> OBJS += piix4acpi.o
> [snip xen*]
> OBJS += exec-dm.o
> OBJS += pci_emulation.o
> OBJS += tpm_tis.o
> OBJS+= pass-through.o pt-msi.o
> OBJS := $(filter-out $(BAD_OBJS), $(OBJS))

These aren't really xen-specific, that's why they don't have a xen or
xen_ prefix.

> That is neither consistent wrt using _ everythere nor all files are
> prefixed consistently.  At least all prefixed ones use underscores.

And that's my point.  I don't see why we should take the burden of
renaming them with dashes.

> >> (3) The files in the qemu source tree don't have a consistent style
> >>     in respect to '-' vs. '_',
> > 
> > There are far more _ than - in qemu.

Just to comment on that. I actually meant in hw/ . There are a lot of -
in the root, because there are block-*, qemu-*, cpu-*, config-*, etc.

> - seems to be only used for
> > things that just share a very generic idea (i.e. usb- and scsi-), while
> > _ seems to be used for things that are more closely related, like arm_*,
> > mips_*, ppc_*, ... xen_* would make sense to my mind.
> To me it looks pretty random,

I doesn't look so much random to me. There are oddities, but the rule
above seems mostly respected.

> And when you count them, then there is no clear winner:
> ~/projects/qemu# find -name "*.[ch]" -print | grep "-" | wc -l
> 293
> ~/projects/qemu# find -name "*.[ch]" -print | grep "_" | wc -l
> 231

Sure, they have different purpose.  As I said, _ for closely related
(like must be compiled together), - for not closely related (i.e.
independant matter that just have some generic link, like the block
interface, scsi or usb bus).

> >> so I had no reason to not use my personal preference ;)
> > 
> > Yes, there is a reason: as I said, that puts a little burden on
> > developpers that have already been working on it in Xen for some time.
> > That also asks Ian to do the move, that makes history digging more
> > tricky, etc.
> git handles renames just fine.

Yes, sure, that's what I meant before ("having a renaming step first").
But that's still work to actually do it, change the Makefiles, and then
when you want to git annotate an old version it becomes tricky: you have
to remember the old name.  So renaming really needs a reason.

> > For more performance, maybe it'd be better to only move the dpy_update()
> > part. It's better to do the xenfb_guest_copy() immediately since the
> > source data is probably already hot in the cache.
> No.  The copy is unsafe.

Ah, because we're writing to ds->data which is handled by the display
backend, right.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>