Re: RFC: ipath ioctls and their replacements

["Bryan O'Sullivan" <bos@pathscale.com>]

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