[linux-dvb] Re: Alternative v4 demux API

[Johannes Stezenbach <js@convergence.de>]

Michael Hunold wrote:
> 
> I don't want to get rid of the "demux" devices, I just think that the 
> filters shouldn't be a part of them. Again: if the user has multiple 
> demuxes and can set multiple PID filters, he might think that these 
> filters are part of the demux. And this isn't the case for any hardware 
> I know. These filters can be attached to demuxes.
> 
> >>The "demuxes" are input selectors and filters are shared.
> 
> >no. If you have an second or third demux device (which means that you 
> >have 2 or 3 seperate demux channels) it's input selector and filters are 
> >independent from the first one.
> 
> But filters are a shared resoource. If demux 1 eats up all filters, then 
>  demux 2 is out of luck. So why not have a "filter device" that you can 
> open as many times as there are filters available?
> 
> >>So it should be possible to open a *filter* as many times as there are 
> >>h/w filters available, not a "demux" device, where the filters are 
> >>shared betwenn all "demuxes".

I think you are discussing nomenclature, not functionality.

If I would create a userspace API it might look like this:

  struct filter *allocate_filter(struct demux *demux);
  int set_filter(strict filter *filter, struct filter_param *p);

[There would be special versions of allocate_filter and set_filter()
for different filter types.]


Now how do we translate this into a device-level API?

It might be cute to have a DVB_DMX_ALLOC_FILTER ioctl, which
when applied to a demux fd returns a new filter fd. But that's
odd, to say the least. Instead we use open() on the demux device
to return a filter fd. The only problem here is that at open()
time we do not know the type of filter, which means allocate_filter()
might succeed while set_filter() will fail with e.g. EBUSY.


I see no point in having a separate filter device, which I then
need to connect to the demux before it is usable. It might fit
nicer to some hardware, but it might as well fit less for other
hw, and IMHO it is more complicated to use.

As for sharing filters between demux devices: You seem to assume
that there is a simple way to tell at open() time whether there
is a filter of the requested type available or not. But that is
not necessarily the case, there might be restrictions which cause
the filter-setting to fail when you try to set the filter parameters.
So this is just a theoretical advantage of your device model.

Instead I prefer to set and start a filter in one ioctl, and only
then do you know if it worked or not. For recording it is important
to ensure that either all PIDs of a service will be recorded, or none;
that's why we proposed to have an array of PIDs as parameter for
DVB_DMX_ADD_PID_FILTER. There is no need for separating filter
allocation and filter usage.


Regards,
Johannes


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.