Re: paddr_t change to 64-bits

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

On 28.09.2010 00:24, Jean-Yves Migeon 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?

Nm, Christos just committed a fix... Thanks!

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