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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
