Hi - finally got through my bug fixlist, so I can get back on to this. On Sunday 21 May 2006 23:39, Trent Piepho wrote: > On Sun, 21 May 2006, Johannes Stezenbach wrote: > > It cannot be called from dvb_unregister_frontend(), as the whole > > point of this exercise is that dvb_attach/detach is optional. > > > > So, it must be called by the card drivers, right after > > the dvb_unregister_frontend() call, and it should simply do: > > > > #define dvb_detach(function) symbol_put_addr(function) > > > > (As a minor complication, fe->ops.release needs to be > > saved in a temporary between dvb_unregister_frontend() > > and dvb_detach().) > > Two other options: > > Add a parameter to dvb_unregister_frontend(fe, int dynamic), that > enables the detach code. > > Create a new function, dvb_unregister_frontend_dynamic(), that > does the same thing. > > This would allow for less duplicated work in the card drivers, and > dynamic attachment would still be optional and controlled by the > driver. Yup. I prefer these options; they mean the minimum changes and hassles in the card drivers, and I prefer keeping alll the guts of it in the dvb-core. As for which? I like the one with the "int dynamic" parameter. > > We should also add a BUG_ON(!fe->ops.release) to > > dvb_register_frontend(), and remove the bogus > > warning printk from dvb_unregister_frontend(). > > Unrelated to dvb_attach(), but some of the radio drivers don't have > release() methods. Yup, the BUG_ON change sounds good. > > Or, maybe we should handle this via Kconfig? So > > that you can add the dvb_detach() to dvb_unregister_frontend(), > > but one can disable dvb_detach/dvb_detach via > > CONFIG_DVB_FRONTEND_STATIC_DEPS? > > This would be a nice ability. Necessary really, if you want to use > symbol_out_addr() and support pre 2.6.17 kernels. I think what ever is > done should support: > > 1. Continue to work with pre 2.6.17 kernels, without dynamic attachment > compatibility if that is too hard. > > 2. Be possible to turn off with Kconfig. If 1 is supported, this should > be trivial. If we keep all the messing with symbol_XXX() in the dvb-core, a simple define would do this. And the same goes for the kernel version compatability. > 3. Not be forced on all drivers. A driver that supports a dozen > front-ends can use dynamic attachment, a driver that supports a single > front-end can continue to use static attachment. Yup. makes sense. > 4. Continue to work with non-module supporting kernels. The symbol_xxx() > macros more or less turn into no-op code when modules are turned off. OK, I do have an updated tree which I have finally completely cleaned and updated to the state we were at before... however don't look at it just now; I need to add the feedback from this email into it and it would be a waste of time commenting on stuff about to change slightly. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
