On Mon, Feb 2, 2015 at 5:00 PM, Greg KH <greg@kroah.com> wrote:
On Mon, Feb 02, 2015 at 04:46:24PM -0600, riya khanna wrote:
The goal is to provide multiple instances of a real device, where each instance could be assigned to a container. This is to enable support for device multiplexing in user space.
Heh, no, don't do it.
Seriously, don't, it's been shot down time and time again in person and in emails. The 2013 Plumbers conference had a whole session on this in which people yelled at me for 45+ minutes, it was fun, I still said no.
Yes, I'm apprised of the LPC '13 and email discussion on device namespaces. In fact the reason I started down this path is because, like you said, the discussion outcome ruled out kernel changes.
I did look at CUSE. However, I realized that not all the device driver's all all operations to be forwarded to CUSE proxy daemon - some device drivers do bookkeeping based on process PID, so CUSE proxy daemon cannot operate on behalf of processes. Performance is another reason.
Have you benchmarked CUSE? It's fast, but the real question is what types of devices are you trying to use this for?
If a device is to be multiplexed, it needs to be done so in the driver for the device, or the subsystem, you can't do it in a "wrapper" driver, or even in userspace, as state will get confused and messed up and it will not work properly in the end, sorry.
The purpose of multiplexing is to either block undesired events/operations on devices (e.g. input, graphics) or respond to the applications based on the in-memory state of device instances. With CUSE, in-memory states can be maintained and mediated in user space. AFAIU, doing device multiplexing in the kernel would also entail the same - maintain in-memory state (replicating data structs) for each virtual device instance, but that also means changing the drivers/subsystem to incorporate this functionality. I may be missing something here, but I'm not sure why maintaining the state in userspace (as a CUSE device) would be messy and not work. I would appreciate more explanation. thanks. -Riya
So would it be acceptable to modify CUSE kernel driver to filp_open(real_device_node), and use corresponding real_filp->f_op->operation() for the file_operations that cannot be forwarded to or are unimplemented by userspace CUSE proxy. Target/real device file operations would act as fallback operations for unimplemented operations.
Nope, do it in each individual subsystem that you want to change. But again, see my above comments, this isn't something that is going to get in easily, if at all, sorry.
good luck,
greg k-h