[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1180983304.10894.19.camel@gaivota>
Date: Mon, 04 Jun 2007 15:55:04 -0300
From: Mauro Carvalho Chehab <mchehab@...radead.org>
To: Thierry Merle <thierry.merle@...e.fr>
Cc: video4linux-list@...hat.com, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Jiri Slaby <jirislaby@...il.com>
Subject: Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
Em Sáb, 2007-06-02 às 11:00 +0200, Thierry Merle escreveu:
>
> Mauro Carvalho Chehab a écrit :
> >>> This seems to be an interesting approach.
> >>>
> >>>
> >>>
> >> Interesting but impossible to do for ioctl calls.
> >> When the application does a ioctl(fd_of_mnt_video0,VIDIOC_G_FMT,&arg)
> >> for example, there is no way for the userspace helper to catch this ioctl.
> >> The application could only open/read from the userspace helper's file
> >> /mnt/video0.
> >> ioctl would still have to be done on the kernel device driver.
> >> I thought also about a /proc interface for decompression algorithms (a
> >> helper would listen on a /proc file and write on another /proc file) but
> >> /proc is not designed for that kind of thing.
> >> A separate library seems to be the simplest solution.
> >>
> >
> > There are some ways for this to work. For example, you may create a
> > helper device for the daemon driver to bind, even requiring it to have
> > root permission.
> >
> >
> Right, but I am afraid that complex userspace/kernelspace context
> changes breaks performance.
Yes, there's a risk.
> Nevertheless, I will start to specify the framework.
> The helper daemon would link to the v4l2-apps/lib.
Ok, thanks!
--
Cheers,
Mauro
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists