[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: paddr_t change to 64-bits
On 01.10.2010 19:26, Matthias Drochner wrote:
> jeanyves.migeon%free.fr@localhost said:
>> IMHO, the ioctl should be versioned; however, how am I supposed to do
>> so? Define AGPIOC_ALLOCATE2, and patch the drm code to use it?
> This doesn't make sense. The agp code is mostly limited
> to 32-bit addresses (GATT entries etc), you'd need range
> checks everywhere an implicite truncation happens.
> As has been said elsewhere, a change of paddr_t width
> causes more problems that it solves, and makes an impression
> of poor engineering. Better fix abuses of paddr_t in
> interfaces relevant to LKMs.
> best regards
True, but the agp(4) code is here, and the API uses paddr_t. So, choices:
1 - fix man page, replace "physical" with "agp_paddr" (?) and make it a
fix type (uint32_t)
2 - keep the API, handle old and new code, cope with that by fixing this
entry to uint64_t (and ifdefing i386).
I just had a look to Solaris and Linux: they both use a uint32_t
equivalent for "physical" (each one uses its own internal type for that).
So I guess that fixing the value to uint32_t is ok (choice 1). Christos
committed the initial fix, so I won't revert his patch and commit that
without prior approval.
Main Index |
Thread Index |