Re: idea on how to break the static dependencies on demodulator modules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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

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

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.

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.

_______________________________________________

linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux