enhanced ioctl

[ndbecker]

BPO	2712
Nosy	@loewis, @benjaminp

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2008-04-29.05:48:38.841>
created_at = <Date 2008-04-28.21:01:19.623>
labels = ['extension-modules', 'type-feature']
title = 'enhanced ioctl'
updated_at = <Date 2008-04-29.10:27:33.154>
user = 'https://bugs.python.org/ndbecker'

bugs.python.org fields:

activity = <Date 2008-04-29.10:27:33.154>
actor = 'ndbecker'
assignee = 'none'
closed = True
closed_date = <Date 2008-04-29.05:48:38.841>
closer = 'loewis'
components = ['Extension Modules']
creation = <Date 2008-04-28.21:01:19.623>
creator = 'ndbecker'
dependencies = []
files = []
hgrepos = []
issue_num = 2712
keywords = []
message_count = 8.0
messages = ['65933', '65938', '65940', '65941', '65949', '65950', '65957', '65959']
nosy_count = 3.0
nosy_names = ['loewis', 'benjamin.peterson', 'ndbecker']
pr_nums = []
priority = 'normal'
resolution = 'works for me'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue2712'
versions = []

[ndbecker]

IIUC, current ioctl is not capable of handling arbitrary argument
types.
This code will allow any arg type (such as structures with pointers to
embedded structures).

The code for _IOC is taken from linux and might not be portable.import

-----

from ctypes import *

libc = CDLL ('/lib/libc.so.6')
#print libc.ioctl

def set_ioctl_argtype (arg_type):
    libc.ioctl.argtypes = (c_int, c_int, arg_type)

IOC_WRITE = 0x1

_IOC_NRBITS=	8
_IOC_TYPEBITS=	8
_IOC_SIZEBITS=	14
_IOC_DIRBITS=	2

_IOC_NRSHIFT=	0
_IOC_TYPESHIFT=	(_IOC_NRSHIFT+_IOC_NRBITS)
_IOC_SIZESHIFT=	(_IOC_TYPESHIFT+_IOC_TYPEBITS)
_IOC_DIRSHIFT=	(_IOC_SIZESHIFT+_IOC_SIZEBITS)


def IOC (dir, type, nr, size):
    return (((dir)  << _IOC_DIRSHIFT) | \
	 ((type) << _IOC_TYPESHIFT) | \
	 ((nr)   << _IOC_NRSHIFT) | \
	 ((size) << _IOC_SIZESHIFT))

def ioctl (fd, request, args):
    return libc.ioctl (fd, request, args)

---

Example (not complete):
class eos_dl_args_t (Structure):
_fields_ = [("length", c_ulong),
("data", c_void_p)]

args = eos_dl_args_t()
args.length = len (c)
args.data = cast (pointer (c), c_void_p)

from eioctl import *

set_ioctl_argtype (POINTER (eos_dl_args_t))

EOS_IOC_MAGIC = 0xF4
request = IOC(IOC_WRITE, EOS_IOC_MAGIC, 0x00, 0) # ignore size

err = ioctl (fd, request, args)

[loewis]

IIUC, current ioctl is not capable of handling arbitrary argument
types.

Can you please be a bit more explicit? What limitation do you see in
fcntl.ioctl, and how does this fragment overcome the limitation?
AFAICT, they do exactly the same thing.

[ndbecker]

On Monday 28 April 2008, Martin v. Löwis wrote:

Martin v. Löwis <martin@v.loewis.de> added the comment:
> IIUC, current ioctl is not capable of handling arbitrary argument
> types.

Can you please be a bit more explicit? What limitation do you see in
fcntl.ioctl, and how does this fragment overcome the limitation?
AFAICT, they do exactly the same thing.

In the example I gave, the ioctl passes a structure:

class eos_dl_args_t (Structure):
    _fields_ = [("length", c_ulong),
                ("data", c_void_p)]

AFAIK, there is no way to do that with fcntl.ioctl, is there?

[loewis]

Passing structures is certainly possible. I'd try

args = struct.pack("iP", len(c), cast (pointer (c), c_void_p).value)
fcntl.ioctl(fd, request, args)

Alternatively,

args = eos_dl_args_t()
...
args_p = cast(pointer(args), c_void_ptr).value
fcntl.ioctl(fd, request, args_p)

should also work, IIUC.

[ndbecker]

On Monday 28 April 2008, Martin v. Löwis wrote:

Martin v. Löwis <martin@v.loewis.de> added the comment:

Passing structures is certainly possible. I'd try

args = struct.pack("iP", len(c), cast (pointer (c), c_void_p).value)
fcntl.ioctl(fd, request, args)

Alternatively,

args = eos_dl_args_t()
...
args_p = cast(pointer(args), c_void_ptr).value
fcntl.ioctl(fd, request, args_p)

should also work, IIUC.

You are correct, both of the above work (at least on x86)

[benjaminp]

So, should we close this?

[loewis]

I think we should close it.

[ndbecker]

OK.