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