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:	Wed, 16 Feb 2011 10:09:44 -0500
From:	Stephen Wilson <wilsons@...rt.ca>
To:	Andy Walls <awalls@...metrocast.net>
Cc:	Stephen Wilson <wilsons@...rt.ca>,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	David Härdeman <david@...deman.nu>,
	Jarod Wilson <jarod@...hat.com>, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [media] rc: do not enable remote controller adapters by default.

Andy Walls <awalls@...metrocast.net> writes:

> On Wed, 2011-02-16 at 01:16 -0500, Stephen Wilson wrote:
>> Having the RC_CORE config default to INPUT is almost equivalent to
>> saying "yes".  Default to "no" instead.
>>
>> Signed-off-by: Stephen Wilson <wilsons@...rt.ca>
>
> I don't particularly like this, if it discourages desktop distributions
> from building RC_CORE.  The whole point of RC_CORE in kernel was to have
> the remote controllers bundled with TV and DTV cards "just work" out of
> the box for end users.  Also the very popular MCE USB receiver device,
> shipped with Media Center PC setups, needs it too.

A similar argument can be made for any particular feature or device that
just works when the functionality is enabled :)

> Why exactly do you need it set to "No"?

It is not a need.  I simply observed that after the IR_ to RC_ rename
there was another set of drivers being built which I did not ask for.

It struck me as odd that because basic keyboard/mouse support was
enabled I also got support for DTV card remote controls.

I don't think there are any other driver subsystems enabling themselves
based on something as generic as INPUT (as a dependency it is just fine,
obviously).

Overall, it just seems like the wrong setting to me.  Is there another
predicate available that makes a bit more sense for RC_CORE other than
INPUT?  Something related to the TV or DTV cards perhaps?


Take care,

>
> Regards,
> Andy
>
>> ---
>>  drivers/media/rc/Kconfig |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
>> index 3785162..8842843 100644
>> --- a/drivers/media/rc/Kconfig
>> +++ b/drivers/media/rc/Kconfig
>> @@ -1,7 +1,7 @@
>>  menuconfig RC_CORE
>>  	tristate "Remote Controller adapters"
>>  	depends on INPUT
>> -	default INPUT
>> +	default n
>>  	---help---
>>  	  Enable support for Remote Controllers on Linux. This is
>>  	  needed in order to support several video capture adapters.
>> --
>> 1.7.3.5
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
steve
--
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