Messages in this thread | | | Subject | Re: RFC: ipath ioctls and their replacements | From | Bryan O'Sullivan <> | Date | Wed, 25 Jan 2006 14:32:41 -0800 |
| |
I've been flailing away at the ioctls in our driver, with a good degree of success. However, one in particular is proving tricky:
> Opening the /dev/ipath special file assigns an appropriate free > unit (chip) and port (context on a chip) to a user process. > Think of it as similar to /dev/ptmx for ttys, except there isn't > a devpts-like filesystem behind it. Once a process has > opened /dev/ipath, it needs to find out which unit and port it > has opened, so that it can access other attributes in /sys. To > do this, we provide a GETPORT ioctl.
I still don't see how to replace this with anything else without performing unnatural acts.
We use struct file's private_data to keep a pointer to the device in use, which works fine for ioctl.
However, if I'm coming into the kernel over a netlink socket, I have no obvious way of going from my table of devices to the processes that have each one open, and I see no evidence that any other device driver tries to do anything like this either.
Short of keeping a reference to the task_struct in the device, or walking the sending process's file table if we receive a netlink message (both of which are disgusting), I see no way to make this ioctl go away.
Am I missing something?
<b
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |