Am Donnerstag, 24. Oktober 2002 00:53 schrieb Greg KH:
> On Thu, Oct 24, 2002 at 12:46:12AM +0200, Oliver Neukum wrote:
> > > Seriously, this is a userspace issue. The driver can set some initial
> > > values that it things is good, but in the end, root can change them to
> > > whatever it wants t
Am Donnerstag, 24. Oktober 2002 00:24 schrieb Greg KH:
> On Thu, Oct 24, 2002 at 12:06:33AM +0200, Oliver Neukum wrote:
> > > > A model of one simple file to be opened per device _is_ simpler
> > > > than a number of files to control various settings.
> > > > Plus, how do you control permissions on
On Thu, Oct 24, 2002 at 12:46:12AM +0200, Oliver Neukum wrote:
> >
> > Seriously, this is a userspace issue. The driver can set some initial
> > values that it things is good, but in the end, root can change them to
> > whatever it wants to, nothing new there.
>
> Most definitely not true.
> 1. Y
On Thu, Oct 24, 2002 at 12:06:33AM +0200, Oliver Neukum wrote:
>
> > > A model of one simple file to be opened per device _is_ simpler
> > > than a number of files to control various settings.
> > > Plus, how do you control permissions on that thing ?
> >
> > The driver controls the initial permis
At 11:57 AM 10/23/2002 +0200, Oliver Neukum wrote:
> The risk being run here (root might change camuser's shutter speed on him /
> disconnect at just the wrong time) is less than the benefit (the shutter
> speed can be changed).
No, most emphatically not. Risking data corruption due to accessing
> > A model of one simple file to be opened per device _is_ simpler
> > than a number of files to control various settings.
> > Plus, how do you control permissions on that thing ?
>
> The driver controls the initial permissions. I think it will be up to
> userspace to control them after that.
Y
On Wed, Oct 23, 2002 at 07:24:34PM +0200, Oliver Neukum wrote:
>
> In short, I am not sure whether writing to driverfs is a good idea
> for simple everyday drivers. You've made something that's inherently
> hard easy to abuse. In a way, you worked too well.
Heh, glad we succeeded :)
> A model of
At 11:57 AM 10/23/2002 +0200, Oliver Neukum wrote:
Why would teaching applications your ioctl be harder than
teaching them your customs procfs or driverfs file?
From a coding point of view an ioctl on a file you do a lot of
ioctls on anyway is far simpler than deducing a path to another file,
open
Am Mittwoch, 23. Oktober 2002 18:45 schrieb Greg KH:
> On Wed, Oct 23, 2002 at 06:37:19PM +0200, Oliver Neukum wrote:
> > > Ok, one of my original questions was if any V4L applications used the
> > > current /proc interface. If they do, as you say, then moving them to
> > > driverfs would not be a
On Wed, Oct 23, 2002 at 06:37:19PM +0200, Oliver Neukum wrote:
>
> > Ok, one of my original questions was if any V4L applications used the
> > current /proc interface. If they do, as you say, then moving them to
> > driverfs would not be a simple thing to do at this time.
>
> The driverfs API is
> Ok, one of my original questions was if any V4L applications used the
> current /proc interface. If they do, as you say, then moving them to
> driverfs would not be a simple thing to do at this time.
The driverfs API is not without problems. In fact, it's close to
opening Pandora's box.
It tu
On Wed, Oct 23, 2002 at 09:20:08AM +0100, Alan Cox wrote:
> On Wed, 2002-10-23 at 07:12, Greg KH wrote:
> > On Tue, Oct 22, 2002 at 11:04:54PM -0700, John Tyner wrote:
> > > > Please don't remove the proc interface. This is a V4L issue. It's in
> > > > there because this is a V4L driver.
> > >
>
Am Mittwoch, 23. Oktober 2002 11:24 schrieb Joe Burks:
> At 10:34 AM 10/23/2002 +0200, Oliver Neukum wrote:
> >Why should shutter speed setting be different from, eg. frame size?
> >They should be settable by the same method.
>
> Agreed. And in V4L2 they can be. Technically it could be set throug
At 10:34 AM 10/23/2002 +0200, Oliver Neukum wrote:
Why should shutter speed setting be different from, eg. frame size?
They should be settable by the same method.
Agreed. And in V4L2 they can be. Technically it could be set through a
vicam-specific ioctl, but if that were the only way to set
Am Mittwoch, 23. Oktober 2002 07:53 schrieb John Tyner:
> > 1. Who can write these settings? How do you control that?
>
> I set permissions to rw-r--r--. Don't these files get owned by root when
> created?
Yes, that's the problem. Consequently device permissions themselves would
have to be 644, wh
On Wed, 2002-10-23 at 07:12, Greg KH wrote:
> On Tue, Oct 22, 2002 at 11:04:54PM -0700, John Tyner wrote:
> > > Please don't remove the proc interface. This is a V4L issue. It's in
> > > there because this is a V4L driver.
> >
> > I saw that you were going to raise the issue on that list. I said
On Tue, Oct 22, 2002 at 11:04:54PM -0700, John Tyner wrote:
> > Please don't remove the proc interface. This is a V4L issue. It's in
> > there because this is a V4L driver.
>
> I saw that you were going to raise the issue on that list. I said the patch
> can wait. Regardless, though, I think tha
> Please don't remove the proc interface. This is a V4L issue. It's in
> there because this is a V4L driver.
I saw that you were going to raise the issue on that list. I said the patch
can wait. Regardless, though, I think that the driverfs is where this kind
of thing is supposed to be going.
A
> 1. Who can write these settings? How do you control that?
I set permissions to rw-r--r--. Don't these files get owned by root when
created?
> 2. The module count handling is wrong.
>These methods don't sleep. Either they are racy or safe with or without
>manipulating the usage count.
I
At 08:55 PM 10/22/2002 -0700, John Tyner wrote:
I saw some discussion as to whether we want to break V4L "standard" by
removing the proc interface, but the driverfs interface provides what was
required of the proc interface: shutter_speed to be settable for each
attached camera individually by a s
Am Mittwoch, 23. Oktober 2002 05:55 schrieb John Tyner:
> Hi,
>
> The attached patch removes vicam.c's proc interface and replaces it with a
> driverfs file called shutter_speed through which the shutter speed can be
> changed for each device.
1. Who can write these settings? How do you control th
Hi,
The attached patch removes vicam.c's proc interface and replaces it with a
driverfs file called shutter_speed through which the shutter speed can be
changed for each device.
This patch also removes the usb_put_dev call from the disconnect routine
as well as adding the up call for the busy mut
22 matches
Mail list logo