performance of pci_device_get_{vendor, device}_name() in X server startup

Mark Kettenis mark.kettenis at
Tue Jun 22 07:44:50 PDT 2010

> Date: Wed, 09 Jun 2010 06:46:52 -0700
> From: Alan Coopersmith <alan.coopersmith at>
> Daniel Stone wrote:
> > On Tue, Jun 08, 2010 at 09:40:55PM -0400, Matt Turner wrote:
> >> On Tue, Jun 8, 2010 at 9:35 PM, Richard Barnette
> >> <jrbarnette at> wrote:
> >>> Still, cost/benefit matters here:  Essentially, the justification
> >>> for all this work is a debug feature (being able to print the information
> >>> in the log when things go wrong), not a performance enhancement.
> >>> I'm not yet persuaded that that feature is worth the identified effort.
> >> I'd still like to hear some opinions from people who do serious
> >> xserver work, but from my perspective there's nothing wrong with only
> >> executing this code if -verbose is used. The output of `lspci -vv` is
> >> already a nearly required piece of any bug report, so I don't think
> >> we're losing anything here.
> > 
> > Indeed.  We already get a more accurate/useful device/vendor identifier
> > string from the driver, and we don't need to know/care about non-GPU
> > devices.
> > 
> > I can see how it would be useful in verbose/error cases, but eh.
>     if (verbose > normal)
> 	system("scanpci >& Xorg.0.log");
> Just have to add a rule to the libpciaccess to actually
> install scanpci by default, but it should provide exactly the same
> info as we were generating/logging from libpciaccess, since it uses
> the same routines.

I don't think using system(3) would be a good idea, since it has some
nasty side-effects.  Also, this probably wouldn't work on OpenBSD
where we have privilige separation, and the execution of scanpci would
fail after we drop root priviliges.

More information about the xorg-devel mailing list