[linux-dvb] Re: V4 API Implementation Q's

[Rob.McConnell@Zarlink.Com]

                      Michael Hunold                                                                                             
                      <hunold@convergen        To:       Rob.McConnell@Zarlink.Com                                               
                      ce.de>                   cc:       Johannes Stezenbach <js@convergence.de>, linux-dvb@linuxtv.org          
                      Sent by:                 Subject:  [linux-dvb] Re: V4 API Implementation Q's                               
                      linux-dvb-bounce@                                                                                          
                      linuxtv.org                                                                                                
                                                                                                                                 
                                                                                                                                 
                      30-Mar-2004 07:41                                                                                          
                      PM                                                                                                         
                                                                                                                                 
                                                                                                                                 











Hi Michael,

> > I'm still curious as to why the output device (OD) proposal was thrown
> > away.  It just seemed logical to have individual ODs so that you could
open
> > them and immediately know whether the resources were available.  Then
you
> > could have IOCTLs specific to each device, making the design more
> > object-oriented.

> The main concern was that ressources (for example pid filters) can be
> shared between various things (ie. pure pid filters, section filters,
> recording filters), so you cannot be sure that your get 32 pid filters
> for example.

Yup, that's a *common* problem, but surely you could share resources
somehow?

> Another point is, that it's easier to use a "query capability" ioctl and
> query how man filters of a certain type are available in the best case,
> then open the device and set the filter. Otherwise you would need to
> parse the device nodes (ie. look if /dev/dvb/adapter0/pid_filter32) or
> have the queury ioctl anyway.

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

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:

e.g. Where we have...

#define DVB_DMX_SET_TS_DECODER_FEED   _IOW(DVB_IOCTL_BASE, 0x23, struct
dvb_dmx_ts_decoder_feed)

...the 0x23 could be...

#define DVB_DMX_SET_FILTER_CMD      0x23

and used for each type of filter/feed output device when setting the
filter/feed specification.

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

> > In fact, this is what I have currently implemented in the HAL code for
my
> > current project.  I have a separate class for each possible type of
feed
> > (general purpose, section table, audio decoder, video decoder, teletext
> > decoder, subtitle decoder, etc.)  with each specific feed inheriting
from a
> > feed superclass.

> If your hardware is that flexible, you won't lose any flexibility by
> using the V4 API as it is. Or do you see any problems?

No problems, just busy writing a generic HAL that could be used for future
devices, not just our own.  ;^)

Thanks,

Rob : )




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