Re: paddr_t change to 64-bits

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

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?

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