0

I have a question related to V4L-DVB drivers. Following the Building/Compiling the Latest V4L-DVB Source Code link, there are 3 ways to compile. I am curious about the last approach (More "Manually Intensive" Approach). It allows me to choose the components that I wish to build and install using the "make menuconfig". Some of these components (i.e. "CONFIG_MEDIA_ATTACH") are used in pre-processor directives that define a function in one shape if defined, and a function in another if not defined (i.e. dvb_attach, dvb_detach) in the resulting modules (i.e. dvb_core.ko) that will be loaded by most of the DVB drivers. What happens if there are two drivers (*.ko modules) on the same host machine, one that needs dvb_core.ko with CONFIG_MEDIA_ATTACH defined and another that needs dvb_core.ko with CONFIG_MEDIA_ATTACH undefined, is there a clean way to handle this?

What is also not clear to me is: Since the V4L compilation environment seems very customizable (by setting the .config file), if I develop a driver using V4L-DVB structures, there is a big chance that it has conflicts with other drivers since each driver has its own custom settings. Is my understanding correct? Thanks! Dave

Dawood
  • 11
  • 3
  • You can't have both simultaneously. Is it a real case or just hypothetical assumption? – 0andriy Aug 12 '16 at 16:32
  • No, it is not a real case that we know about. But it seems very reasonable that it may happen. We are developing a V4L-DVB compatible driver, and we are using the dvb-core in the V4L-DVB which will eventually be compiled into a module called dvb-core.ko which will be called by our driver, and distributed with our drivers. Will this not create a conflict if it just happens that there is a user out there that has a dvb-core.ko obtained from some other source (e.g. V4L)? – Dawood Aug 12 '16 at 17:05
  • You **have to** upstream your changes to avoid such a situation. Otherwise you alone are to blame. – 0andriy Aug 12 '16 at 17:07
  • Ok, in a situation where I had changed the dvb-core, I would agree with you, and I would take the **blame**(lol). But in this case, I am not "Changing the dvb-core". It is customizable by setting some components to "m", "n", or "y" in a file called .config that is used when compiling the V4L structure on my local machine. Simply, the existance of such an option tells me that the developer of the dvb-core did not think that there will be 2 different drivers using the dvb-core on one machine simultaneously on his mind when he developed the dvb-core. Is my understanding correct? – Dawood Aug 12 '16 at 17:34
  • I'm not quite familiar with media subsystem, in particularly DVB, though my logic tells me that since there are a lot of drivers are existing and working the develpers gave a thought about an architecture. And due to our discussion is about hypothetical case I think I stop here. – 0andriy Aug 13 '16 at 13:07
  • ok, thanks for your time Andy. Anyone else has some opinion to share? – Dawood Aug 17 '16 at 12:25

0 Answers0