On Jun 4, 2010, at 10:45 PM, Jarod Wilson <jarod@xxxxxxxxxxxx> wrote:
On Fri, Jun 4, 2010 at 7:16 PM, Jon Smirl <jonsmirl@xxxxxxxxx> wrote:
On Fri, Jun 4, 2010 at 5:17 PM, Jarod Wilson <jarod@xxxxxxxxxxxx>
wrote:
On Fri, Jun 4, 2010 at 4:17 PM, Jarod Wilson <jarod@xxxxxxxxxx>
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.
There's also the two-pass approach. Just split the address (or feature
flags) across two slightly different ioctl cmds.
--
Jarod Wilson
jarod@xxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
