[PATCH 5/6] xfree86: fbdevhw: remove secondary way to find fb PCI device

[Michel Dänzer]

On Mon, 2010-05-31 at 17:48 +0300, Vignatti Tiago (Nokia-D/Helsinki)
wrote: 
> On Mon, May 31, 2010 at 04:36:51PM +0200, ext Michel Dänzer wrote:
> > On Mon, 2010-05-31 at 17:10 +0300, Vignatti Tiago (Nokia-D/Helsinki)
> > wrote: 
> > > On Mon, May 31, 2010 at 03:58:46PM +0200, ext Michel Dänzer wrote:
> > > > On Mon, 2010-05-31 at 16:16 +0300, Tiago Vignatti wrote: 
> > > > > fbdevhw already relies in libpciaccess, which in turn relies in sysfs to probe
> > > > > devices. If sysfs is reporting wrong values then we're doomed anyway. So we
> > > > > totally rely on sys and this second suspicious way to match fb <-> PCI becomes
> > > > > superfluous.
> > > > 
> > > > So the /sys/bus/pci/devices/%04x:%02x:%02x.%d/graphics/fb%d /
> > > > /sys/bus/pci/devices/%04x:%02x:%02x.%d/graphics:fb%d files were already
> > > > there in the minimum Linux kernel version required by libpciaccess?
> > > 
> > > I don't know the answer, but why you care?
> > 
> > Because otherwise this change will break at least the fbdev driver on
> > some systems.
> 
> How it will break? I though I was pretty clear regarding the commit message
> saying that we have to trust on sysfs otherwise we're doomed. When I mentioned
> libpciaccess there was just to mention that we are already relying on sysfs
> for other purposes.

sysfs didn't appear in its current form instantly but in evolutionary
steps. AFAIR the files above (which with your change are required for
the matching to work) were added relatively recently, and it might be
possible for libpciaccess to otherwise work fine with kernels which
didn't have them. Now I may well be wrong about this, but it would be
nice if you could check rather than asserting the code is 'superfluous'.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer