From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KR8fO-00056f-Ip for qemu-devel@nongnu.org; Thu, 07 Aug 2008 12:48:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KR8fN-00056T-2o for qemu-devel@nongnu.org; Thu, 07 Aug 2008 12:48:45 -0400 Received: from [199.232.76.173] (port=49095 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KR8fM-00056N-VA for qemu-devel@nongnu.org; Thu, 07 Aug 2008 12:48:44 -0400 Received: from smtp.ctxuk.citrix.com ([62.200.22.115]:21834 helo=SMTP.EU.CITRIX.COM) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KR8fM-0002Zi-J9 for qemu-devel@nongnu.org; Thu, 07 Aug 2008 12:48:44 -0400 Date: Thu, 7 Aug 2008 17:48:43 +0100 From: Samuel Thibault Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qemu Message-ID: <20080807164843.GR6604@implementation.uk.xensource.com> References: <4899AD19.8060606@redhat.com> <20080806140132.GL4448@implementation.uk.xensource.com> <4899B06F.2090101@redhat.com> <20080806142526.GN4448@implementation.uk.xensource.com> <20080806221047.GE4486@implementation> <489AA532.7040006@redhat.com> <20080807105352.GC6604@implementation.uk.xensource.com> <489AE6E2.2040500@redhat.com> <20080807125402.GF6604@implementation.uk.xensource.com> <489B2023.8030101@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <489B2023.8030101@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: xen-devel@lists.xensource.com, Ian Jackson , Markus Armbruster , qemu-devel@nongnu.org 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. Samuel