[linux-dvb] unique IDs for struct dvb_demux_feed

Holger Waechtler holger at qanu.de
Mon Feb 14 20:38:20 CET 2005

Patrick Boettcher wrote:

> On Mon, 14 Feb 2005, Johannes Stezenbach wrote:
>> Patrick Boettcher wrote:
>>> When rewriting the skystar2 driver I saw something, which maybe can 
>>> be put
>>> into an upper layer:
>>> Every driver, which's hardware supports PID filtering (in the demod or
>>> anywhere else), implements a similar mechanism: They hold a table or a
>>> static list with at least an unique ID, a pid value and an 
>>> active-switch.
>>> Each time the start_feed-callback is called they look for a free 
>>> entry in
>>> this list and reserve it until it is freed by the 
>>> stop_feed-callback. The
>>> unique ID can be understood as the position in the pid-filter-table 
>>> of the
>>> hardware, just incrementing the feed_count is of course not enough 
>>> and ID
>>> can be reused. For examples, see dvb-dibusb-pid, skystar2, 
>>> ttusb-budget.
>>> The easiest solution would be to add a unique ID to struct 
>>> dvb_demux_feed.
>>> Some ugly code duplicates can then be removed.
>>> Please have a look at the attached patch. Does this small change in
>>> dvb_demux.[ch] is sufficient, or did I miss anything?
>> I guess dvb_demux.[ch] was written with devices like the Nova cards
>> in mind. If your tiny patch lets us drop unnecessary code from
>> dvb-dibusb-pid, skystar2, ttusb-budget then it can't be wrong ;-)
> I'm not sure at all, but could it be, that adding another field to 
> this struct, breaks compatibility with binary-only drivers? At least 
> when they access dvb_demux_feed passed to start_feed. If so, is adding 
> the new field at the end of the struct a solution?
> Please enlighten me about the secrets of breaking binary 
> compatibility. :) 

adding new, optionally used fields at the end of the struct maintains 
binary compability.


More information about the linux-dvb mailing list