Re: paddr_t change to 64-bits

[christos%astron.com@localhost (Christos Zoulas)]

In article <4CA66E1E.9040302%free.fr@localhost>,
Jean-Yves Migeon  <jeanyves.migeon%free.fr@localhost> wrote:
>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
>> Matthias
>
>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.

Please change it as you like.

christos