Re: [PATCH] pcictl: simplify its usage

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

David Young wrote:
> On Thu, Jun 11, 2009 at 11:26:48AM +0200, Manuel Bouyer wrote:
>> On Thu, Jun 11, 2009 at 11:16:53AM +0200, Christoph Egger wrote:
>>> Manuel Bouyer wrote:
>>>> On Thu, Jun 04, 2009 at 11:05:21PM +0200, Christoph Egger wrote:
>>>>> Manuel Bouyer wrote:
>>>>>> On Thu, Jun 04, 2009 at 10:28:18PM +0200, Christoph Egger wrote:
>>>>>>>> But what we have right now does work !
>>>>>>>> You just need to use the autoconf index instead of the bus number.
>>>>>>>>
>>>>>>>> Also, minor(dev) is not the PCI bus domain but the autoconf index.
>>>>>>> Can I assume, that the 'i' iterator matches the autoconf index?
>>>>>>> If yes, then I can compare 'i' with minor(dev).
>>>>>> Yes, and device_lookup() and device_lookup_private() does it for you.
>>>>>> But with this we're back to the old code. You have to use different
>>>>>> /dev/pciN for the different busses. I don't see this as a problem;
>>>>>> I think all what you need is the list of PCI busses (list of autoconf 
>>>>>> indexes)
>>>>>> which you could get by a specific ioctl (either a "get the list" ioctl,
>>>>>> or a "get the next bus" ioctl).
>>>>> At work, there's a 4-way Opteron machine having two primary PCI roots.
>>>>> You find the second one via ACPI. The pciN starts with 128 on that
>>>>> machine. Should we have 255 /dev/pciN device files then?
>>>> You mean that you have more than 128 PCI busses on this machine ?
>>>> Or just that you have
>>>> pci1 at xxx bus 128 ?
>>>> In this case, you'll access it with /dev/pci1 and not /dev/pci128
>>>> It if's really pci128 at xxx bus 128 then there's something I don't
>>>> understand in autoconf, and I'd like to see the dmesg for this machine !
>>>>
>>> I still haven't access to that machine yet. So I still have to owe you
>>> the answer.
>>>
>>> In this discussion, it has been proposed more than once to extend the
>>> pciio ioctl. Also the real root issue has been identified: We don't
>>> support PCI domains.
>>>
>>> In attached diff I propose three new ioctl which deprecate
>>> PCI_IOC_BDF_CFGREAD, PCI_IOC_BDF_CFGWRITE and PCI_IOC_BUSINFO.
>>>
>>> I also would like to introduce a new argument which specifies
>>> the PCI domain. But I am unsure how to name it since -d is already
>>> in use for 'device'. If we can use -p for 'pcidomain' then we
>>> go do:
>>>
>>> pcictl list -p 0
>>>
>>> to enlist all busses and devices from pci domain 0.
>> How is it different from
>> pcictl pci0 list ?
>> (yes, it's per-bus and not per-domain but I've yet to see a clear
>> definition of what a PCI domain is - one PCI domain per bus maybe ?).
> 
> I think that by a "PCI domain," Christoph means the independent
> bus/device/function namespace on each bus.  There is one PCI domain per
> host bridge.

Correct.

How do we handle interrupts from two PCI devices on two
different PCI domains having the same bus, device and function number ?


> 
> Maybe a pcictl command that lists the host bridges would be handy,
> 
> # pcictl hb
> pci0
> pci5
> pci7

I got this sort of proposal several times.

> Then you can show all of the PCI devices on each bus with a script such
> as:
> 
> pcictl hb | while read hb; do
>       echo host bridge $hb
>       jot 256 0 | xargs -n 1 pcictl $hb list -b
> done

Even simpler:

pcictl hb | while read hb; do
      echo host bridge $hb
      pcictl $hb list
done


Christoph