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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home