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

Re: [Xen-devel] [PATCH] pci: constify domain parameter of pci_get_pdev_by_domain



>>> On 11.09.17 at 11:22, <roger.pau@xxxxxxxxxx> wrote:
> On Mon, Sep 11, 2017 at 03:09:54AM -0600, Jan Beulich wrote:
>> >>> On 08.09.17 at 20:08, <andrew.cooper3@xxxxxxxxxx> wrote:
>> > As as bdf is also quite a common unit, how about:
>> > 
>> >>
>> >> typedef union {
>> >>     uint32_t sbdf;
>> >>     struct {
>> > 
>> > union {
>> >     uint16_t bdf;
>> >     struct {
>> 
>> Yes.
>> 
>> >>         union {
>> >>             struct {
>> >>                 uint8_t  func : 3, /* Function */
>> >>                          slot : 5; /* Device   */
>> > 
>> > dev or device, surely?
>> 
>> Yeah, comment and field name would better match (or the comments
>> could perhaps go away altogether). While "slot" is a common term
>> here, with this being inside something called "sbdf" I agree "device"
>> or "dev" (in the former case it should also be "function", but I prefer
>> the shorter variants) should be used here.
> 
> I've used "slot" because I thought it was more common in the pci code,
> we already have kind of weird naming, for example we usually use
> PCI_SLOT(devfn). I don't have an opinion here, so I will switch to
> 'dev'.
> 
> I'm not sure what's the best way to introduce this, would you like it
> to be part of my PCI emulation series?

That would be fine, as would be an independent prereq patch.

> I certainly don't plan to switch existing callers unless I need to
> modify them anyway.

Indeed. New code would be appreciated to use the new struct,
but existing code will better be switched over time.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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