[linux-dvb] Re: Alternative v4 demux API

[Rob.McConnell@Zarlink.Com]

Hi Holger and Co....

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

OK, I'm trying to make the point that we need to consider how easy to add
this option in for debugging, internal development and final release to
customers.  A module parameter would be OK - just means that the script
that loads the module has to call "insmod" with the required value.  Not a
problem for people like us, but when you start dealing with customers who
haven't used Linux/Unix before you get all kinds of "help me" messages ; )

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

Yet another flag to add to the arsenal : )

> > 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'll give some more info on a later email.

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

Absolutely.

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

Dough!

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

I'll give it a shot when I get a bit of time.

Off home now, so probably speak 2U all on Mon - via the magic of email....

Have a good one!

Rob : )






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