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

[Michael Hunold <hunold@convergence.de>]

Hello Rob,

Johannes is on vacation, so I'll step in and try to answer your questions.

On 03/29/04 12:27, Rob.McConnell@Zarlink.Com wrote:
> Anyway, just to get it straight, when we open the demux device in read mode
> to obtain an fd (and to allocate memory for the feed/filter), we won't be
> performing any checks on the overall number of filters in the system. 
Yes.

> When
> we perform the IOCTL to actually setup a feed/filter, this is where the
> underlying hardware will be checked to see if there are any available PID
> filters left and then an error can be returned to indicate if no
> filters/feeds are available.  Is this correct?
Yes.

> BTW, have we had any comments off our other STB friends as regards to the
> V4 API?  Does it meet their requirements as well?
We're keeping in mind the most popular STB hw that our software is 
running on. So far we didn't see any problems and the "STB friends" 
didn't complain either. But I admit that most likely problems will be 
noticed when it comes to writing the drivers...

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

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.

And last, the kernel and the unix "everything-is-a-file" approach is 
well-known and *not* object oriented. 8-)

The V4 API tries to be a thin layer above existing hardware. If you want 
to have your software run on a variety of different platforms, you need 
to have some sort of abstraction layer ("middleware") anyway.

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

> That's all for now,
> Rob : )
CU
Michael.


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