On Sat, Nov 10, 2012 at 1:16 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
> On Sat, Nov 10, 2012 at 12:31 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote:
>> On Fri, Nov 9, 2012 at 10:47 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote:
>>> On Mon, Nov 5, 2012 at 12:20 PM, Donald Dutile <ddutile@xxxxxxxxxx> wrote:
>>>>
>>>> static const struct attribute_group *pci_dev_attr_groups[] = {
>>>> &pci_dev_attr_group,
>>>> +#ifdef CONFIG_PCI_IOV
>>>> + &sriov_dev_attr_group,
>>>> +#endif
>>>
>>> should move sriov_dev_attr_group related code to
>>> drivers/pci/iov.c
>>> or driver/pci/iov_sysfs.c
>>>
>>> and kill those CONFIG_IOV.
>>
>> Bjorn,
>>
>> please check attached patch that separate sriov_dev_attr_group out.
>> it is against to your pci/don-sriov branch.
>
> The convention is to include patches inline, which makes them easier
> to review. I know gmail makes that hard. I use mutt or stacked git
> to do it.
yes, gmail web client should support plain attachment.
so you are using mutt with smtp enabled ?
>
> I'm not opposed to moving the SR-IOV sysfs stuff out of pci-sysfs.c.
> Since these patches haven't been merged yet, you should work it out
> with Don first, so we can merge it in the right place to begin with,
> rather than merging them and then immediately moving them.
sure. it should be out of pci-sysfs.c at first place.
I thought that you are going to merge your pci/don-sriov.
BTW, when you redo pci/don-sriov, please add acked-by from GregKH for
first two patches.
>
> Personally, I would put it all in pci/iov.c rather than creating a new
> file just for this. That would also avoid the question of whether it
> should be "iov_sysfs.c" or "iov-sysfs.c". All the other files in
> drivers/pci use a hyphen. All the files in subdirectories of
> drivers/pci use an underscore. A minor but annoying difference.
yeah, looks like should be iov-sysfs.c to keep them consistent.
iov.c is already about 800 lines. better not to stuff more code into it anymore.
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
