FW: wrapper device driver

[riya khanna]

On Mon, Feb 2, 2015 at 5:00 PM, Greg KH <greg at 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