FW: wrapper device driver

[greg@kroah.com (Greg KH)]

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

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.

> 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.

> 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