[Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.

[noreply@sourceforge.net]

Bugs item #555817, was opened at 2002-05-14 19:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 22:06

Message:
Logged In: YES 
user_id=29957

possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470
I've only lightly tested it, not with any calls that return
useful values in the return code (couldn't find any easily, 
didn't feel like figuring out userspace drivers right now :)
Give it a whirl...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 20:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470