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] [day] [month] [year] [list]
Message-ID: <20080514030120.7521b9a9@gaivota>
Date:	Wed, 14 May 2008 03:01:20 -0300
From:	Mauro Carvalho Chehab <mchehab@...radead.org>
To:	Mike Isely <isely@...ox.com>
Cc:	isely@...ly.net, Michael Krufky <mkrufky@...uxtv.org>,
	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Guennadi Liakhovetski <g.liakhovetski@...gutronix.de>
Subject: Re: [patch] video: build fix for drivers/media/video/pvrusb2/

On Tue, 13 May 2008 11:02:05 -0500 (CDT)
Mike Isely <isely@...ly.net> wrote:

> On Tue, 13 May 2008, Mike Isely wrote:
> 
> > On Tue, 13 May 2008, Mauro Carvalho Chehab wrote:
> > 
> > > On Tue, 13 May 2008 00:03:02 -0400
> > > "Michael Krufky" <mkrufky@...uxtv.org> wrote:
> > > 
> > > > 
> > > > 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:
> > 
> > Where is the loop that results in a circular reference?  No part of V4L 
> > or DVB depends (or otherwise has any reliance) on VIDEO_PVRUSB2.  All 
> > Mike Krufky is trying to set up is that VIDEO_PVRUSB2 should only depend 
> > on DVB_CORE if the DVB part of the driver (i.e. VIDEO_PVRUSB2_DVB) has 
> > been enabled.  Without VIDEO_PVRUSB2_DVB selected, then DVB_CORE is not 
> > required by the driver.
> > 
> > I've been quiet about this issue because I'm not a kconfig expert, but 
> > you've lost me with this conclusion.
> > 
> >   -Mike
> 
> Never mind.  I think I see it, and will figure out the rest off-line.

The solution were not as easy as I've originally imagined. VIDEO_MEDIA logic
were broken. So, all tuners were still broken.

I needed to fix VIDEO_MEDIA logic first, to obey to this truth table:

CONFIG_VIDEO_DEV        CONFIG_DVB_CORE         CONFIG_VIDEO_MEDIA
        N                       N                       N
        N                       M                       M
        N                       Y                       Y
        M                       N                       M
        M                       M                       M
        M                       Y                       M
        Y                       N                       Y
        Y                       M                       M
        Y                       Y                       Y

After this change, a simple dependency add solved the reported issue:

 config VIDEO_PVRUSB2
	tristate "Hauppauge WinTV-PVR USB2 support"
	depends on VIDEO_V4L2 && I2C
+	depends on VIDEO_MEDIA  # Avoids pvrusb = Y / DVB = M

I've tested the logic. seems fine now.

I did a quick review at the other modules that has hybrid support (cx88,
saa7134, em28xx, bttv) and they seemed ok to my eyes. Yet, I didn't test.

---

There are other configurations that seem to be broken. For example, if
V4L_CORE=m and DVB_CORE=y, a V4L driver should be 'M'. So, a tuner should also
be 'M', otherwise, it will break compilation. a DVB support for that card will
also be 'M', at the drivers I've reviewed.

However, a DVB-only driver can be 'Y', but can select a tuner. This will cause
a breakage.

I'll try to simulate some of those issues and see what happens.

Anyway, I've added severak Kbuild fixes at my -git tree:

http://www.kernel.org/git/?p=linux/kernel/git/mchehab/v4l-dvb.git

I intend to send the fixes I have later today. Now, I need to sleep ;)

Cheers,
Mauro
--
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