On Tue, Feb 03, 2015 at 09:34:31AM -0600, riya khanna wrote: > > You didn't answer my question of "which specific devices do you care > > about" :( > > > > You can't "filter" device commands (see the before-mentioned cdrom mess, > > you have learned from history, right?) And you can't assume you know > > what the in-kernel state of devices really are, as they are getting > > commands from the hardware itself that changes this state, not all > > changes come from userspace. > > > > Thanks for the explanation and sorry for not answering your question. > I care about input and graphics subsystem (no specific device) because > there are abstractions already available in the kernel for them (e.g. > evdev, drm kms). I'm not talking about filtering device-specific > commands through ioctl(). I understand the problem with that. However, > I was wondering if one could take advantage of generic interfaces > (e.g. evdev) and mediate accesses in user space through ioctl. You have looked at the bazillion different DRM ioctls, right? And understand the state machine complexities that happen between the kernel and userspace for a DRM device? Have you written up how you would handle mediating that interface in a reasonable manner? > For > example, if a container is in the background (i.e. user not > interacting with it), then all inputs should be blocked to it, but if > it becomes active again inputs must be redirected to its virtual > devices. That seems foolish, what happens if that background container tried to set the state of a specific device? How can you reliably fail that? > This can be done through evdev interface's EVIOCGRAB and > EVIOCREVOKE ioctls. evdev already gives you all the needed hooks to try to do something like this from userspace. There shouldn't need to be anything extra to do here, otherwise, how would input devices work today in multi-session systems? I would go back and talk to who ever is thinking that they want this type of solution, to just sit down and look at the DRM ioctl interface. After they are done screaming, you shouldn't have to worry about being given impossible tasks anymore :) Best of luck, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
