>>> On 16.12.14 at 21:08, <julien.gr...@linaro.org> wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -2,6 +2,7 @@ obj-y += bitmap.o
> obj-y += core_parking.o
> obj-y += cpu.o
> obj-y += cpupool.o
> +obj-y += device.o
Shouldn't this instead be two lines, one using HAS_PCI and the second
HAS_DEVICE_TREE?
> @@ -75,8 +76,19 @@ struct pci_dev {
> #define PT_FAULT_THRESHOLD 10
> } fault;
> u64 vf_rlen[6];
> +
> + struct device dev;
> };
I'm not convinced yet that growing this structure (of which we have
quite many instances on some systems) is really worth it, in particular
on x86 where we (so far) only have one device type anyway.
> +#define pci_to_dev(pcidev) (&(pcidev)->dev)
> +
> +static inline struct pci_dev *dev_to_pci(struct device *dev)
> +{
> + ASSERT(dev->type == DEV_PCI);
> +
> + return container_of(dev, struct pci_dev, dev);
> +}
While the former is const-correct, I dislike the inability of passing
pointers to const into helper functions like the latter. I can't think
of a good solution other than introducing a second const variant
of it, but I suppose we should try to find alternatives before
adding such a construct that moves us in a direction opposite to
getting our code more const-correct.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
