Re: paddr_t change to 64-bits

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

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.

Cheers!

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost