[PATCH RFC]: Generic Linux multi-domain PCI handling

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David S. Miller wrote:
> From: Ian Romanick <idr at us.ibm.com>
> Date: Tue, 03 Jan 2006 09:39:21 -0800
> 
>>Ironically, the first part of the year for me is going to be occupied
>>working on some similar stuff.  There are some pretty significant
>>problems with 32-bit X-servers on 64-bit pSeries hardware.  In addition
>>to non-zero PCI domains, devices in domain 0 get mapped above
>>0x7fffffff.  This causes problems when doing an mmap of /dev/mem in
>>32-bit mode. :(
> 
> Not if you end up using mmap64() properly.  We had a similar problem
> with a tool that mmap()'d network device registers in order to test
> PCI PIO latency.  And the fix was simply to add "-D_FILE_OFFSET_BITS=64"
> to the build command line.  You can probably do something similar.

I looked into doing that.  However, all of the values used to store the
offsets are hard coded as "unsiged long".  On the platforms that exhibit
the problem, that's only 32-bits.  To fix that we'd have to go through
and find, then fix every single place that stores such an offset.  If
I'm going to go to that much effort, I'm going to fix the core problem
rather than just putting more bandaids on it.

This is also part of the reason that I wanted to wrap the existing data
structures & typedefs with something slightly higher level.

>>This is similar to the approach that I was going to take.  However, I
>>was going to go a bit further.  Rather than using /proc, I was going to
>>add a new version of pciFindNext that iterated over the entries in
>>/sys/bus/pci/devices.  That way only devices that actually exist get
>>iterated.  The guess-and-check method used in the existing pciFindNext
>>implementations has always bothered me.  Of course, if /sys doesn't
>>exist it would fall back to the older method.
> 
> That's a great way to do this.  And if you'll go that far, it's probably
> time to just do the right thing and actually use libpci.a from pciutils.
> We're reimplementating a lot of code already in there that knows
> perfectly well how to decode the various /proc/bus/pci and /sys/bus/pci
> incantations depending upon what kernel version and what filesystems
> are mounted.

That's actually a very good idea!  I'll look into that.  How stable is
that libpci.a ABI?  Meaning, would doing this add a dependency to X that
turns out to be a major pain-in-the-behind to track?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDuuU/X1gOwKyEAw8RAq8jAJ4yDUS0AwPb60JXB3b9iDBAGDiAgwCfRKLX
OqgD5T8vuXh4eANKJlaspY0=
=ikUw
-----END PGP SIGNATURE-----