[linux-dvb] Re: Alternative v4 demux API

[Holger Waechtler <holger@convergence.de>]

Rob.McConnell@Zarlink.Com wrote:
> Hi All,
>
>
> > Rob.McConnell@Zarlink.Com wrote:
> >
> > > Having the ability to select the delivery format (parallel or serial)
> of
>
> > > the TS/PS to a potential input/selector device would be useful. I guess
> > > this would be an ioctl on the front-end device. That's one ioctl for
> the
>
> > > front-end device API.... : )
>
> > Why would this be useful? I think the board designer decides if he wants
> > to use serial or parallel FE output and would not connect both?
>
> I agree that in the field, you would only have a fixed input (parallel or
> serial), but because we are using development boards that test every aspect
> of the silicon, we do require this functionality (typical h/w bods).
Don't you think a module parameter would suit this purpose better?

>  Also,
> when providing software to 3rd parties or customers who develop their own
> hardware, then having the ease to choose the option makes things far more
> simpler than having them try and hack kernel/driver code or have "us" do it
> for them.
Even then the userspace software should not be responsible to care about 
the actual hardware design details -- remember: The kernel is a Hardware 
Abstraction Layer which should provide a common API to userspace no 
matter what hardware is actually hidden by the abstraction layer.


> Having a single demux device per input channel is not a problem.  It is
> when you start looking at the outputs, that's when you start to find "what
> if" or "Oh bugger I forgot to support this flag/feature/new bit of crazy
> hardware".  Having a group of "output" devices/filters that are connected
> to a "demux" device would be logically more sane (each one performing a
> different function).
Then we would not only need to invent a new flag for every new hardware 
but invent an entire new device, not?

> We definitely need to address "extensibility" as we don't want to sit down
> again and have all these debates about how pretty our own API looks or
> whatever. ;^) Designing it in a way that allows one to insert a new module
> that performs a specific filtering capability would be ideal.  The layer
> that gets passed the filtered data can be kept generic in that it passes
> the data up to user-space as required.
Hmm, I don't see why extending the API by inventing a new decoder device 
including the corresponding output flag should be more complicated than 
your approach. Can you please elaborate this a bit more in detail?


> I agree, it's not that straight forward, but with 2.6 and the larger 32
> bits for the device type this would be easier.  What about devfs, would
> that help out?
Since 2.4 ist still used in embedded environments and will probably be 
for a long time we can't rely on 2.6-only features.

And in 2.6 it's not possible anymore to use a devfs-only system without 
the major/minor limitations. Kudos to the guy who crippled this.

> I think its time to come up with some real API header files again.  If we
> propose both ideas in different files and let people comment on them, then
> we may get more feedback.
yes, please do so -- maybe then it gets clearer why your approach might 
get simpler at the end.

Holger



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