On Mon, Feb 2, 2015 at 5:00 PM, Greg KH <greg@xxxxxxxxx> 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
