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?
>
> Even with "only" 32 feature flags, I think we'd still be just fine,
> there appear to be only 15 feature flags at present, and I doubt many
> more features need to be added, given how long lirc has been around.
>
> --
> Jarod Wilson
> ja...@wilsonet.com
>
--
Jon Smirl
jonsm...@gmail.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
