Re: [PATCH] pcictl: simplify its usage

[David Young <dyoung%pobox.com@localhost>]

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.

Maybe a pcictl command that lists the host bridges would be handy,

# pcictl hb
pci0
pci5
pci7

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

> Also I'm almost sure you're trying to solve a problem which
> doesn't exists.

I don't see a problem that it takes a kernel change to fix, myself.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933