Marian Jancar wrote: > Gerd Knorr wrote: > > > > > Would it make sense to register multiple minors per card? > > > > IMHO not. I can't see how this makes writing drivers easier. It is just > > different. With multiple minors you have one device context per minor > > number, with multiple opens you have one device context per filehandle. > > That's all. Using multiple minors does'nt solve any real problems. > > > > Applications still might get -EBUSY if they try to capture because > > I would like to avoid this. What else should happen if the resources of the hardware are exhaused? There is simply no way around this. Ok, you can hide that in a userspace library. This moves the problem to another place, it does not solve it. If two applications want to capture at the same time while the hardware can't do that, one of the two will receive a "sorry, you can't right now". > driver abble of it could allow start another capture with an ioctl) Hmm, ok. You want start another capture with an ioctl? Fine, which format the driver should use? Which input? This is alot more that just another ioctl. For every capture you have to keep a context, i.e. a set of parameters (format, size, ...). You can specify the context either by switching them using ioctls or passing a context ID to every ioctl. With multiple opens you can simply hook the context data into the filehandle's private_data, i.e. you get the context switching *for free*. Moving the context switching completely to userspace doesn't work either as this would'nt work with hardware which can do multiple captures in parallel. I still fail to see how the userland library makes driver writing easier or helps in other ways. 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 /.
