> > Yes, of course. Last time I got responses along the lines "multiple opens > > makes driver writing harder, that's why it is bad". That's why I wanted > > make clear that supporting multiple opens isn't mandatory for the drivers. > > Well, it does support multiple opens, but it is spec'd that only one > open can have capturing privileges. And exactly this I'd like to be changed. > Multiple capturing opens can produce subtle repercussions in the > sematics of various ioctls. For example, suppose an app opens a driver > and does a GET-FORMAT (or any other kind of query) while there are two > capturing opens active. The format of which open should be returned? You have to keep the current capture format per filehandle (otherwise you'll get alot of nasty races). Therefore GET-FORMAT will *not* return the data of the other opens, it returns the settings for the current handle (which in turn can be initialized at open() time with some default format or with whatever the hardware currently uses). > If > the driver requires both opens to use the same format, which open gets > control, and will that mess up the app that doesn't have control? STREAMON will lock down the capture ressources, i.e. the driver guaranties that nobody else can mess up the settings and that it will be able to capture at full frame rate until it calls STREAMOFF. Means whoever calls STREAMON first has the control over the hardware, and the other one will get a -EBUSY if the driver can't handle the request. > Of course, a driver writer can do whatever he pleases behind the scenes, > as long the ioctl semantics are preserved such that apps, and therefore > users, are happy. Yes. But I'd like to see the exact ressource locking semantics for multiple opens in the API spec. As mentioned a few mails back I think the current API is fine, it is just a documentation issue. Gerd -- Protecting the children is a good way to get a lot of adults who cant stand up for themselves. -- seen in some sig on /.
