On Fri, Jun 4, 2010 at 7:16 PM, Jon Smirl <jonsm...@gmail.com> wrote:
> On Fri, Jun 4, 2010 at 5:17 PM, Jarod Wilson <ja...@wilsonet.com> wrote:
>> On Fri, Jun 4, 2010 at 4:17 PM, Jarod Wilson <ja...@redhat.com> wrote:
>>> On Fri, Jun 04, 2010 at 02:57:04PM -0400, Jon Smirl wrote:
>> ...
>>>> > From what I'm seeing, those are the current used ioctls:
>>>> >
>>>> > +#define LIRC_GET_FEATURES _IOR('i', 0x00000000, unsigned
>>>> > long)
>>>> > +#define LIRC_GET_LENGTH _IOR('i', 0x0000000f, unsigned
>>>> > long)
>>>>
>>>> Has this been set into stone yet? if not a 64b word would be more future
>>>> proof.
>>>
>>> Nope, not set in stone at all, nothing has been merged. A patch I was
>>> carrying in Fedora changed all unsigned long to u64 and unsigned int to
>>> u32, and my current ir wip tree has all u32, but I don't see a reason why
>>> if we're going to make a change, it couldn't be to all u64, for as much
>>> future-proofing as possible.
>>
>> Hrm, struct file_operations specifies an unsigned long for the ioctl
>> args, so doesn't that mean we're pretty much stuck with only 32-bit
>> for the ioctls?
>
> I haven't written an IOCTL in a while, but how would you pass a 64b
> memory address?
Well, you wouldn't use struct file_operations' ioctl definition if you
wanted to do so on a 32-bit host. :)
Its definitely possible using a different ioctl definition (see
gdth_ioctl_free in drivers/scsi/gdth_proc.c, for example), but we're
currently bound by what's there for file_operations.
--
Jarod Wilson
ja...@wilsonet.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
