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. :) regards, Patrick. -- Mail: patrick.boettcher@xxxxxxx WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/
