From: Malte Vesper
Sent: 02 February 2015 21:43
To: riya khanna
Subject: RE: wrapper device driver
Why don't you implement your wrapper as a userspace library?
From: kernelnewbies-boun...@kernelnewbies.org
[kerneln
I guess a userspace library approach won't be transparent to the applications.
On Mon, Feb 2, 2015 at 3:44 PM, Malte Vesper
wrote:
>
>
> From: Malte Vesper
> Sent: 02 February 2015 21:43
> To: riya khanna
> Subject: RE: wrapper device driver
>
> Why don't
On Mon, Feb 02, 2015 at 04:05:35PM -0600, riya khanna wrote:
> I guess a userspace library approach won't be transparent to the applications.
Look at cuse, I think it provides what you are wanting to do here.
But as you really didn't say what your goals are, it's hard to
determine.
good luck,
g
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.
I did look at CUSE. However, I realized that not all the device
driver's all all operations to be forwarded to CUSE pr
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 supp
On Mon, Feb 2, 2015 at 5:00 PM, Greg KH 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
On Mon, 02 Feb 2015 17:50:43 -0600, riya khanna said:
> 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.
Those who don't remember the history of filterin
On Mon, Feb 2, 2015 at 8:49 PM, wrote:
> On Mon, 02 Feb 2015 17:50:43 -0600, riya khanna said:
>> 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.
>
>
On Mon, Feb 02, 2015 at 05:50:43PM -0600, riya khanna wrote:
> On Mon, Feb 2, 2015 at 5:00 PM, Greg KH 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 contai
On Mon, Feb 2, 2015 at 9:15 PM, Greg KH wrote:
> On Mon, Feb 02, 2015 at 05:50:43PM -0600, riya khanna wrote:
>> On Mon, Feb 2, 2015 at 5:00 PM, Greg KH 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,
On Tue, 03 Feb 2015 09:34:31 -0600, riya khanna said:
> (e.g. evdev) and mediate accesses in user space through ioctl. 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
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 k
12 matches
Mail list logo
