Re: paddr_t change to 64-bits

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

In article <4CA119A8.2010009%free.fr@localhost>,
Jean-Yves Migeon  <jeanyves.migeon%free.fr@localhost> wrote:
>On 27.09.2010 22:47, Iain Hibbert wrote:
>> On Mon, 27 Sep 2010, Thor Lancelot Simon wrote:
>> 
>>> On Mon, Sep 27, 2010 at 08:33:23PM +0100, Iain Hibbert wrote:
>>>> Hi
>>>>
>>>> the recent change to arch/i386/include/types.h which forces paddr_t to be
>>>> 64-bits for userland has (I think) broken my xserver which passes a
>>>> structure agp_allocate with ioctl which contains a paddr_t. The kernel is
>>>> expecting this to be 32-bits but the xserver passes 64-bits and the ioctl
>>>> is now unrecognized (as the size is embedded in the cmd value)
>>>
>>> It sounds more to me like the struct agp_allocate is broken.  If a physical
>>> address is 64 bits, then it's 64 bits.
>> 
>> struct agp_allocate from <sys/agpio.h> contains paddr_t and it is the
>> definition of paddr_t which is broken because <i386/types.h> now defines
>> it differently for non-PAE kernel (32-bit) and userland (64-bit).
>
>Correct. I missed that one, and as expected, drm causes trouble with the
>paddr_t change :/
>
>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?
>
>AGPIOC_ALLOCATE => old code, assume 32 bits paddr_t as interface (old
>i386 interface). Kernel will convert to 32 bits depending on its i386 mode.
>
>AGPIOC_ALLOCATE2 => new code, assume 64 bits paddr_t as interface.
>Kernel code will pass a 64 bits paddr_t for physical.
>
>Opinions?

I've already fixed it. I am not sure what to do in the PAE case though.

christos