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 Thursday 04 May 2006 23:29, Trent Piepho wrote:
> On Thu, 4 May 2006, Andrew de Quincey wrote:
> > > First, I would like it better if symbol_put_addr() would be fixed
> > > so we could use my dvb_detach() idea ;-)
> > > It would mean that no changes to the frontend drivers are
> > > necessary at all.
> >
> > I suppose Trent's patch to fix it would also provide a good indicator as
> > to whether people think symbol_put_addr() is going to be kept or not,
> > depending on its reception by lkml (or whoever its sent to).
>
> I posted my patch on lkml, but no one responded.  I'm not a kernel
> developer, so that's not too surprising.  I doubt anyone who cares about
> the symbol_xxx code in the kernel even read it.  I'm used to it.  My patch
> to fix the broken makefile to this list was totally ignored too.  Maybe if
> someone else better known posted my patch, it would get attention.

I'm sorry if I missed it :(

> Maybe, using symbol_put_addr() need not wait for a patched kernel.   Could
> a fixed version be included in dvb-core that is compiled on older kernels?
>
> I already tried a version with symbol_put_addr (with my patch to fix it)
> that doesn't require any extra modification of the demodulator drivers.
>
> In dvb_attach(), I just used the code I already posted here.  It does not
> do a symbol_put() and so keeps the lock on the symbol.
>
> In the card driver, I modified the dvb_remove() function to call
> symbol_put_addr() on the release() method from the frontend ops struct. 
> Since the locking is at the module level, not the symbol level, it doesn't
> have to be the same symbol that was used in symbol_get(), just a symbol
> from the same module.

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. 

I was also intending using dvb_attach() for stuff like the lnbp21 module as 
well - so we'd need to record somewhere that that was in use so it can be 
detached properly... with the current system, it just overrides release() so 
it gets called first, and then it calls the original release() method. 

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.

> This worked fine.  The frontend module was auto-loaded if it wasn't loaded
> already.  The FE can't be unloaded while the card driver is still loaded.
> When the card driver is unloaded, the FE use count is decremented, allowing
> the FE to be unloaded.  A driver doesn't use dvb_attach() should be able to
> use the same frontend module as one that does.  card drivers that only
> support a single FE have no reason to use dvb_attach(), and so don't have
> to.

Sounds good.

_______________________________________________

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