On 10/07/15 20:21, Greg KH wrote:
On Wed, Oct 07, 2015 at 11:55:01AM +0300, Vlad Zolotarov wrote:
On 10/07/15 11:46, Greg KH wrote:
On Tue, Oct 06, 2015 at 08:17:36PM +0300, Vlad Zolotarov wrote:
Add the ability for underlying device drivers to register the ioctl
commands. This is useful when some interaction with the user space
beyond sysfs capabilities is required, e.g. query the interrupt mode
or bind eventfd to interrupt notifications (similarly to vfio ioctl
VFIO_DEVICE_SET_IRQS).
Signed-off-by: Vlad Zolotarov <vl...@cloudius-systems.com>
---
drivers/uio/uio.c | 15 +++++++++++++++
include/linux/uio_driver.h | 3 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 8196581..714b0e5 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -704,6 +704,20 @@ static int uio_mmap(struct file *filep, struct
vm_area_struct *vma)
}
}
+static long uio_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
+{
+ struct uio_listener *listener = filep->private_data;
+ struct uio_device *idev = listener->dev;
+
+ if (!idev->info)
+ return -EIO;
+
+ if (!idev->info->ioctl)
+ return -ENOTTY;
+
+ return idev->info->ioctl(idev->info, cmd, arg);
+}
As Stephen said, I will not take this, sorry. It opens up the ability
to add "new system calls" to a huge range of crappy drivers, it's
something that vendors have been trying to push for years and is
something that I will not allow.
Ok. Another alternative could be to add new sysfs attributes for the MSI-X
functionality similarly to what is done with "maps".
Would it be acceptable?
If you get everyone else here to agree that this is the interface you
all are going to be using, sure. All I care is that you not add ioctl
to the UIO interface.
Ok then. Thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
