linux-kernel - Re: [GIT PULL for v3.5-rc1] media updates for v3.5

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]

Message-ID: <4FBEB72D.4040905@redhat.com>
Date:	Thu, 24 May 2012 19:33:17 -0300
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Media Mailing List <linux-media@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL for v3.5-rc1] media updates for v3.5

Hi Linus,

Em 24-05-2012 17:42, Linus Torvalds escreveu:
> Btw, I only noticed now, because I normally don't build DVB on my main
> machine with "oldconfig" - why the hell does DVB add tuners with
> "default m"?
> 
> Why would *anybody* with an old config ever want to get those new
> drivers as modules?
> 
> Get rid of all the stupid
> 
>   default m if DVB_FE_CUSTOMISE
> 
> because there's no reason for them. If somebody wants that module,
> they can damn well press the 'm' button. There's absolutely no reason
> for it to default to on.
> 
> This is true of *all* drivers. No driver (and certainly DVB is not at
> all an exception) is so important that it should be "default m" (or
> y).
> 
> There are a few valid reasons to use "default m/y", but I don't see
> that that is the case here:
> 
>  - if you have an *existing* driver that got split up, and "make
> oldconfig" with that old driver enabled would result in it no longer
> supporting the same capability, then a
> 
>      default OLD_DRIVER_WAS_ENABLED
> 
>    is appropriate - it makes "oldconfig" work the way people expect it to work.
> 
>    But this is only when that piece of hardware used to be supported
> already, it's irrelevant for new hardware.
> 
>  - if it's *such* a basic piece of hardware that you simply don't want
> to bother the user with an insane default. Like supporting an ATKBD
> driver on a PC etc.
> 
>    This simply isn't true for media devices.
> 
> So stop doing the silly "enable this driver by default for old
> configurations". It's *wrong*.

For a DVB driver to work, it is generally required to select 3 drivers:
a bridge driver, a tuner driver and a demodulator driver.

The Kconfig default for DVB_FE_CUSTOMISE is 'n'. So, if no DVB bridge is selected,
nothing will be compiled.

The same bridge driver can be used with several different tuner and demods. 
On almost all cases, the tuner and demod drivers are connected via an I2C bus.

The Kconfig logic was built in a way that, when a bridge driver is selected,
all the drivers that might be required will also be selected.

For example:

config DVB_USB_DIB0700
	tristate "DiBcom DiB0700 USB DVB devices (see help for supported devices)"
	depends on DVB_USB
	select DVB_DIB7000P if !DVB_FE_CUSTOMISE
	select DVB_DIB7000M if !DVB_FE_CUSTOMISE
	select DVB_DIB8000 if !DVB_FE_CUSTOMISE
	select DVB_DIB3000MC if !DVB_FE_CUSTOMISE
	select DVB_S5H1411 if !DVB_FE_CUSTOMISE
	select DVB_LGDT3305 if !DVB_FE_CUSTOMISE
	select DVB_TUNER_DIB0070 if !DVB_FE_CUSTOMISE
	select DVB_TUNER_DIB0090 if !DVB_FE_CUSTOMISE
	select MEDIA_TUNER_MT2060 if !MEDIA_TUNER_CUSTOMISE
	select MEDIA_TUNER_MT2266 if !MEDIA_TUNER_CUSTOMISE
	select MEDIA_TUNER_XC2028 if !MEDIA_TUNER_CUSTOMISE
	select MEDIA_TUNER_XC5000 if !MEDIA_TUNER_CUSTOMISE
	select MEDIA_TUNER_XC4000 if !MEDIA_TUNER_CUSTOMISE
	select MEDIA_TUNER_MXL5007T if !MEDIA_TUNER_CUSTOMISE

This driver supports 82 different types of devices. When this driver is selected, 
all supported variants of tuners and frontends are selected, meaning that any of the 
82 types will work.

Keeping DVB_FE_CUSTOMISE not set is the recommended way, as the options 
DVB_FE_CUSTOMISE and MEDIA_TUNER_CUSTOMISE are there only to allow
advanced users to disable the devices that aren't needed.

For example, one of the ISDB-T devices I have here requires only those drivers
to work:
	DVB_USB_DIB0700		- USB bridge and I2C controller
	DVB_DIB8000		- ISDB-T demodulator
	DVB_TUNER_DIB0070 	- the PLL tuner driver

If just DVB_USB_DIB0700 is selected, the bridge driver will be loaded, 
but no DVB devices will appear, as the driver won't initialize properly.

On the other hand, if those tree modules are selected, the remaining tuners/demods
can be disabled, as the bridge driver won't require them.

So, this is an option that it is useful for embedded systems, where
there's just one specific hardware model to be used.

So, in order to avoid non embedded/advanced users that might enable DVB_FE_CUSTOMISE
by mistake to generate lots of not-a-bug bugzillas, when the DVB customise options
are enabled, all I2C modules are selected by default, using the "default m if DVB_FE_CUSTOMISE"
logic.

So, I think that, in this specific case, the "default m if DVB_FE_CUSTOMISE"
makes sense.

Regards,
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/