tech-kern archive

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

Re: [PATCH] pcictl: simplify its usage



On Thursday 04 June 2009 12:20:34 Manuel Bouyer wrote:
> On Thu, Jun 04, 2009 at 12:15:08PM +0200, Christoph Egger wrote:
> > On Thursday 04 June 2009 11:48:25 Manuel Bouyer wrote:
> > > On Wed, Jun 03, 2009 at 11:28:22PM +0200, Christoph Egger wrote:
> > > > Hi,
> > > >
> > > > A (shell,perl,python,whatever) script that wants
> > > > a list of all pci devices has something to do like
> > > > this:
> > > >
> > > >   for i in 0 1 2 3 4 5 6 7 8 9
> > > >   do
> > > >      pcictl pci$i list
> > > >   done
> > > >
> > > > And that still doesn't even get all devices if
> > > > there's another pci controller starting with
> > > > 128 (found on 4-way Opteron machines).
> > > >
> > > > Attached patch makes pcictl to really enlist all devices
> > > > with:
> > > >
> > > >   pcictl list
> > > >
> > > > if you want to have back old functionality, you can (still) do
> > > >
> > > >   for i in 0 1 2 3 4 5 6 7 8 9
> > > >   do
> > > >      pcictl list -b $i
> > > >   done
> > > >
> > > >
> > > >
> > > > If you want to dump a PCI device the current way is:
> > > >
> > > >    pcictl pci$i dump -d $j -f $k
> > > >
> > > > New way with this patch is:
> > > >
> > > >    pcictl dump -b $i -d $j -f $k
> > > >
> > > >
> > > > The main motivation for this work is to have an easy way
> > > > for xen to get the pci-passthrough feature for Xen 3.3 and newer.
> > >
> > > Why not just add a command to list the PCI busses,
> >
> > You want something like lspci in the base system ? Why should we maintain
> > two tools for the same thing ?
>
> I meant, a command to pcictl (like list and dump, something like listbus)

It wouldn't work that way.
The functionality provided by pcictl is limited by the device file.
For example, /dev/pci3 only lets it operate with devices attached on pci3.
I need pcictl to operate on *all* devices therefore I had to fold the pci
device files into one. This is the main functional change from the kernel 
side.

> > > instead of changing the interface in a non-backward-compatible way ?
> >
> > Compile it with COMPAT50 #defined and it understands the old syntax as
> > well.
>
> Do you intend to have COMPAT50 defined by default ?

This is a good point to turn into a survey.
I will do what people agree with.
If the answer is yes, should I define COMPAT50 in the pcictl.c source or in 
the Makefile ?

Christoph


Home | Main Index | Thread Index | Old Index