Re: paddr_t change to 64-bits

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

On 02.10.2010 18:12, Christos Zoulas wrote:
> In article <4CA66E1E.9040302%free.fr@localhost>,
> Jean-Yves Migeon  <jeanyves.migeon%free.fr@localhost> wrote:
>> 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.

Thanks; I think we should mimic what other kernels do, so "physical"
will become an uint32_t. That will fix the (ab)use of paddr_t for this
interface, as Matthias said.

xserver should pass the correct value there, whatever the mode currently
is for kernel.

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