lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 13 May 2008 12:30:25 -0400
From:	mkrufky@...uxtv.org
To:	mchehab@...radead.org
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org,
	g.liakhovetski@...gutronix.de, isely@...ox.com
Subject: Re: [patch] video: build fix for drivers/media/video/pvrusb2/

Michael Krufky wrote:
> Mauro Carvalho Chehab wrote:
>> On Tue, 13 May 2008 00:03:02 -0400
>> "Michael Krufky" <mkrufky@...uxtv.org> wrote:
>>
>>  
>>> On Mon, May 12, 2008 at 10:54 PM, Mauro Carvalho Chehab
>>> <mchehab@...radead.org> wrote:
>>>    
>>>> On Sun, 11 May 2008 08:34:06 -0400
>>>>  "Michael Krufky" <mkrufky@...uxtv.org> wrote:
>>>>
>>>>  > On Sun, May 11, 2008 at 3:21 AM, Ingo Molnar <mingo@...e.hu> wrote:
>>>>  > >
>>>>  > > x86.git testing found the following build failure:
>>>>  > >
>>>>  > >  drivers/built-in.o: In function `pvr2_dvb_feed_thread':
>>>>  > >  pvrusb2-dvb.c:(.text+0x127e78): undefined reference to 
>>>> `dvb_dmx_swfilter'
>>>>  > >  drivers/built-in.o: In function `pvr2_dvb_adapter_exit':
>>>>  > >  pvrusb2-dvb.c:(.text+0x128357): undefined reference to 
>>>> `dvb_net_release'
>>>>  > >  pvrusb2-dvb.c:(.text+0x12836f): undefined reference to 
>>>> `dvb_dmxdev_release'
>>>>  > >  [...]
>>>>  > >
>>>>  > > with this config:
>>>>  > >
>>>>  > >  
>>>> http://redhat.com/~mingo/misc/config-Sun_May_11_07_06_35_CEST_2008.bad
>>>>  > >
>>>>  > > the reason for the missing symbols is this combination:
>>>>  > >
>>>>  > >  CONFIG_VIDEO_PVRUSB2=y
>>>>  > >  CONFIG_DVB_CORE=m
>>>>  > >
>>>>  > > i.e. pvrusb2 is built-in, dvb-core is modular.
>>>>  > >
>>>>  > > This patch solves the problem by adding a dependency on 
>>>> DVB_CORE - this
>>>>  > > is used by other drivers such as au0828 as well. This way the 
>>>> pvrusb2
>>>>  > > driver can still be built, but if dvb-core is a module then it 
>>>> will
>>>>  > > correctly be a module as well and cannot be built-in.
>>>>  > >
>>>>  > > Signed-off-by: Ingo Molnar <mingo@...e.hu>
>>>>  > > ---
>>>>  > >  drivers/media/video/pvrusb2/Kconfig |    2 +-
>>>>  > >  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>  > >
>>>>  > > Index: linux/drivers/media/video/pvrusb2/Kconfig
>>>>  > > 
>>>> ===================================================================
>>>>  > > --- linux.orig/drivers/media/video/pvrusb2/Kconfig
>>>>  > > +++ linux/drivers/media/video/pvrusb2/Kconfig
>>>>  > > @@ -1,6 +1,6 @@
>>>>  > >  config VIDEO_PVRUSB2
>>>>  > >        tristate "Hauppauge WinTV-PVR USB2 support"
>>>>  > > -       depends on VIDEO_V4L2 && I2C
>>>>  > > +       depends on VIDEO_V4L2 && I2C && DVB_CORE
>>>>  > >        select FW_LOADER
>>>>  > >        select MEDIA_TUNER
>>>>  > >        select VIDEO_TVEEPROM
>>>>  > >
>>>>  >
>>>>  > Ingo,
>>>>  >
>>>>  > VIDEO_PVRUSB2 should not depend on DVB_CORE unless 
>>>> VIDEO_PVRUSB2_DVB
>>>>  > is selected, which already depends on DVB_CORE.
>>>>  >
>>>>  > For example, if a user has VIDEO_PVRUSB2_DVB not selected, then 
>>>> your
>>>>  > patch would generate a false dependency on DVB_CORE.
>>>>
>>>>  Maybe we can make pvrusb2 dependent of VIDEO_MEDIA. This is a 
>>>> DVB_CORE ||
>>>>  VIDEO_DEV. So, pvrusb should be 'm' in this case.
>>>>       
>>> That sounds like it would be OK, although something like this would
>>> probably be better:
>>>
>>>  config VIDEO_PVRUSB2
>>>        tristate "Hauppauge WinTV-PVR USB2 support"
>>> -       depends on VIDEO_V4L2 && I2C
>>> +       depends on VIDEO_V4L2 && I2C && (DVB_CORE if VIDEO_PVRUSB2_DVB)
>>>        select FW_LOADER
>>>        select MEDIA_TUNER
>>>        select VIDEO_TVEEPROM
>>>     
>>
>> This doesn't look to be a good idea, since VIDEO_PVRUSB2_DVB depends on
>> VIDEO_PVRUSB2. So, you'll create a circular dependency. The syntax I've
>> proposed seems cleaner. Of course, it needs to be tested. IMO, all 
>> hybrid
>> devices should be dependent of VIDEO_MEDIA. This will help to avoid 
>> this kind
>> of issue.
>>
>>  
>>> I don't know if that syntax works for "depends on" , but it does work
>>> for select.
>>>
>>> if "depends on FOO if BAR" doesnt work, would adding "select DVB_CORE
>>> if VIDEO_PVRUSB2_DVB" solve the problem?
>>>     
>>
>> Also, this leads into a circular reference.
> Mauro,
>
> You're right -- I didn't consider the circular dependency.
>
> Your suggestion (depends on VIDEO_MEDIA) seems like the right way to go. 
Mauro,

It has just occurred to me -- there is yet another issue that is created 
by the dependency on VIDEO_MEDIA .....

The pvrusb2 driver *always* has a V4L2 interface exposed, and optionally 
can have a DVB interface.

So, VIDEO_PVRUSB2 will *always* depend on VIDEO_DEV, but conditionally 
depend on DVB_CORE.

...Sounds like the correct clause should be:

depends on VIDEO_V4L2 && I2C && VIDEO_DEV && VIDEO_MEDIA

...what do you think?

-Mike Krufky
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ