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.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.