Next steps for pci-rework branches

[Ian Romanick]

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

Mark Kettenis wrote:
>> 4. Replace any calls to the old PCI accessor routines (e.g.,
>> pciReadLong, xf86MapPciMem, etc.) with calls to the new accessor
>> routines.  The APIs are similar, but there are some differences.  The
>> biggest difference, which bit me during the Savage driver conversion, is
>> that the new routines only allow an entire BAR to be mapped, whereas the
>> old routines allowed subranges of a BAR to be mapped.  I suggest
>> converting subrange mappings to full BAR mappings *before* converting to
>> the new interfaces.  This is the approach that I took with the Savage
>> driver.
> 
> Sorry to bring this up again, but this means that the libpciaccess API
> is *broken*.  There needs to be an interface for subrange
> mappings. Since:
> 
> 1. Mappings can take up valueable resource in the kernel.
> 
> 2. Mapping the whole BAR might expose "dangerous" registers that could
>    be accidentally (or on purpose by a malicious attacker) accessed.
>    It's much better to not map these registers in the first place.
> 
> Please fix the linpciaccess API before asking people to convert more
> drivers and port it to other OSes.

I fail to see how any of this is relevant.  All of the drivers that I
have surveyed map the entire range anyway!  Instead of doing it all in
one go, they do it in disjoint pieces.  If you can explain to me how
doing a single mapping per BAR vs. multiple mappings to cover the entire
BAR uses more kernel resources or expose additional security risks, I'm
all ears.  For extra credit, please show how the additional kernel
resources outweigh the added complexity in the library or the driver.
And I don't mean hand waving.  Show me some hard data.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFE4JlZX1gOwKyEAw8RAkWfAJ9mtxjcKoLe6DeG7DkWBJJA7YeT/gCffxkb
CiVXk4j6zXarvKaH1anyyxk=
=xTWL
-----END PGP SIGNATURE-----