On Thu, 4 May 2006, Andrew de Quincey wrote: > There is one issue with using any of the methods in dvb_frontend_ops - the API > is designed so that multiple devices can hook into the ops structure and > override functions or even chain them - those methods aren't necessarily > pointing at the demod module. It could be pointing at something else. In fact > the lnbp21_attach() method does exactly this. That does throw a monkey wrench in my plan. How about this: The dvb_frontend struct gets a new field, 'module'. The FE attach function sets it to THIS_MODULE, ie. it points to the FE module. After the card driver calls the FE's release() method, it does a put on the module field (it saves it before it calls release of course). If the FE attach function is called without using dvb_attach() it doesn't matter, the module field is set and then just ignored. This doesn't use symbol_put_addr() and doesn't use fe_ops either. Still doesn't have any nice chaining ability. This means all the FEs have to add the module field and code to set it. The first method didn't require the FEs to do anything, and if the kernel was compiled without modules the whole attach/get/put business would just automagically disappear. > This is kinda why I am so keen on having the release() methods themselves do > the counting; it would automatically tidy up these chained devices. Is there a race condition if that is done? If the card driver puts the module after release, the module stays "locked" until nothing is using it in any way. If the release() method puts itself, then the module is "unlocked" while one of its methods is still executing. Maybe that's not a problem and the kernel module unload code takes care of it? _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
