From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH for 4.6 07/13] xen: Introduce a generic way to describe device Date: Thu, 18 Dec 2014 15:56:09 +0000 Message-ID: <5492F919.2010701@linaro.org> References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org> <1418760534-18163-8-git-send-email-julien.grall@linaro.org> <549165F102000078000502B8@mail.emea.novell.com> <54915B3E.4010702@linaro.org> <54916CFA020000780005032F@mail.emea.novell.com> <54917F29.8070901@linaro.org> <5491BAB902000078000C40C6@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1dR2-0007rC-8g for xen-devel@lists.xenproject.org; Thu, 18 Dec 2014 15:56:16 +0000 Received: by mail-wg0-f44.google.com with SMTP id b13so2024669wgh.31 for ; Thu, 18 Dec 2014 07:56:11 -0800 (PST) In-Reply-To: <5491BAB902000078000C40C6@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: keir@xen.org, ian.campbell@citrix.com, manish.jaggi@caviumnetworks.com, tim@xen.org, stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org Hi Jan, On 17/12/2014 17:17, Jan Beulich wrote: >>>> Julien Grall 12/17/14 2:04 PM >>> >> On 17/12/14 10:46, Jan Beulich wrote: >>>>>> On 17.12.14 at 11:30, wrote: >>>> Having a generic way to describe device will really help ARM code (see >>>> IOMMU). >>>> >>>> If we don't have a such thing, we may need to duplicate quite a lots of >>>> code. Which will make hard to maintain. >>> >>> Not really, if e.g. "device" was simply an alias of "pci_dev" on x86. >> >> How many pci_dev instance you could have on a platform? 1000? Though it >> might be a high value but that mean we use 2k more of RAM. > > Sure the total amount isn't big. But these days everyone thinks that way, and > data size gets grown without much consideration. And you shouldn't just think > about RAM cache utilization. I will go ahead with the aliasing. >> It doesn't seem to bad for the benefit to have a clear code. > > Aliasing device and pci_dev for x86 would yield similar clarity afaict. To be sure, by aliasing you mean creating a typedef? For x86: typedef struct pci_dev device_t; And for ARM: typedef struct device device_t; > >>>>>> +#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. >>>> >>>> Oh right. I didn't though about that case. I will turn this inline >>>> function into a macro. >>> >>> I'm afraid that won't help, as you still need to specify a type as >>> 2nd argument to container_of(), and that type can't be both >>> const and non-const at the same time, i.e. you can't easily >>> inherit the const-ness of the passed in pointer. >> >> I agree that we will drop the const-ness. But is it really an issue? >> >> We won't have many place where we don't want to modify the pci_dev. > > Did you check (including places where const could be added)? But at least > you didn't have to drop and const-s, so I'm not heavily objecting the change > you propose. The only usage will be in the IOMMU code where most of the time we require a non const version. At least on the SMMU driver, we have to store data per-device. This is to know what is the SMMU master for this device. -- Julien Grall