Would the "query capability" ioctl return a "snap-shot" of the actual number of filters left of a certain type or would it return the max number of filters for each type? I would prefer the former, as you could easily have the scenario that there are 32 PID filters in a demux device that can be allocated as a general purpose, section, or record filter. Then if you allocated a section filter, for example, there would only be 31 filters/feeds left to _share_ between them all (instead of 32). We should have a count in the driver for each filter/feed type that is kept up-to-date. So in the case where all filter types map down to a PID filter/feed in the h/w, the count for each type would be adjusted simultaneously (all decremented by one when allocating a filter).
If you have a hardware that mixes all these kind of filters to one device, you'll have a hard time to calculate how many filters are actually available of each kind.
In the later case, you could end up opening too many fd's and finding out that you couldn't set a filter/feed of the required type. You would then have to close the fd and this then gets a little convoluted. Wouldn't it be _cleaner_ to have an "open" on the specific filter/feed device which would either succeed or not depending on the actual number of filters left (you could still use the count method as above). Then you could issue the necessary ioctl to setup the filter/feed specification. In fact, the actual IOCTLs ordinal numbers could be kept the same between devices:
You'll always have race conditions. If you query for the number of available pidfilters and the number is 1, there can always be another data-harvesting application in the background that can get this last pidfilter and there is nothing you can do about it.
IMHO this stuff isn't critical, ie. you don't need to have atomic open_and_set() function, this is simply too heavy.
Setting a pidfilter can always fail (if you specified invalid parameters), so you'll have to check the return code of the SETFILTER ioctls anyway. EBUSY (in case there are no filters available) is just another error code you need to check.
Each output feed/filter device could also have its own "query caps" ioctl that would be better targeted towards the devices capabilities. For example, you wouldn't want to know how many audio filters were available for a section filter output device.
I am just trying to make sure that we are all completely happy with the API, as it is pretty near the mark at the moment. : )
Please don't get me wrong, your ideas are all perfectly valid. But please keep in mind that the kernel<->user communication should be leightweight and simple, especially to keep complexity out of the kernel.
Thanks, Rob : )
CU Michael.
-- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
