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

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

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.

~/xen/qemu-dm# grep ^OBJS xen-hooks.mak
OBJS += piix4acpi.o
OBJS += xenstore.o
OBJS += xen_platform.o
OBJS += xen_machine_fv.o
OBJS += xen_machine_fv.o
OBJS += xen_blktap.o
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))

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

>> (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. - 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, probably depending on the person creating
that file.  And when you count them, then there is no clear winner:

~/projects/qemu# find -name "*.[ch]" -print | grep "-" | wc -l
~/projects/qemu# find -name "*.[ch]" -print | grep "_" | wc -l

>> 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.

> 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.



Xen-devel mailing list



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