Trent Piepho wrote:
> On Sat, 15 Apr 2006, Oliver Endriss wrote:
> > Trent Piepho wrote:
> > > What about doing things the old fashioned way, with a library? Stick all the
> > > nim (WTF is nim?) code into a directory, one nim per c file, and compile them
> > > all into a nim.a library. Then each driver can link against nim.a and will
> > > get the nim functions it needs, and not the ones it doesn't. The prototypes
> > > could be in a single nim.h, or in nim_{foo,bar,baz}.h for each nim.
> >
> > Please correct me if I'm wrong:
> > A library does not wourk because all drivers share the same name space.
> > If you try to load two drivers which have the same 'NIM' linked-in, you
> > will get a 'duplicate symbol' error...
>
> I guess that's a pretty good reason not to use a library, if that's how it
> works. The symbols would be internal to the module, not exported or resolved at
> link time, so maybe there isn't a problem. I'll admit I don't really know the
> details of how modules are linked by the kernel.
>
> I suppose I should just try it and see...
>
> Seems to work fine. I added non-static global functions with the same name to
> two modules, and they loaded fine, each calling their own version of the
> function. Not exactly the same as pulling the function in when the module
> is linked at compile time, but I think that will work too.
Thanks for testing! That makes sense. I forgot that only symbols
declared with 'EXPORT_SYMBOL' are visible to other kernel modules...
Anyway, a library would require
- two files (header+implementation) instead of one header
- additional changes to the Makefiles
And it would not avoid code duplication.
@all:
After considering everything posted in both threads I still believe that
one small header file per nim/tuner/whatever is the best solution:
- easy to implement/understand
- minimal changes -> unlikely to break a driver
If someone thinks that it should be done in a different way he should
take over now (write code, convert drivers and commit it).
Sorry, I cannot spend more time on this (non-)issue because there are
real problems waiting in my todo queue. :-(
I vote to accept Perceval's patch and commit it. If you can agree on a
prefix/sub-directory name I will modify the patch accordingly.
Apparently it is not easy to find a good filename prefix. ;-)
CU
Oliver
--
--------------------------------------------------------
VDR Remote Plugin available at
http://www.escape-edv.de/endriss/vdr/
--------------------------------------------------------
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
