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

[Samuel Thibault]

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