On Wed, Oct 07, 2015 at 11:55:01AM +0300, Vlad Zolotarov wrote:
If you get everyone else here to agree that this is the interface you
On 10/07/15 11:46, Greg KH wrote:
On Tue, Oct 06, 2015 at 08:17:36PM +0300, Vlad Zolotarov wrote:Ok. Another alternative could be to add new sysfs attributes for the MSI-X
Add the ability for underlying device drivers to register the ioctlAs Stephen said, I will not take this, sorry. It opens up the ability
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 <vladz@xxxxxxxxxxxxxxxxxxxx>
---
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);
+}
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.
functionality similarly to what is done with "maps".
Would it be acceptable?
all are going to be using, sure. All I care is that you not add ioctl
to the UIO interface.
greg k-h