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: <5024B4A5.9090309@redhat.com>
Date:	Fri, 10 Aug 2012 09:13:41 +0200
From:	Hans de Goede <hdegoede@...hat.com>
To:	David Rientjes <rientjes@...gle.com>
CC:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL for 3.6-rc1] media updates part 2

Hi,

On 08/09/2012 10:03 PM, David Rientjes wrote:
> On Thu, 9 Aug 2012, Mauro Carvalho Chehab wrote:
>
>> Yeah, that would work as well, although the code would look uglier.
>> IMHO, using select/depend is better.
>>
>
> Agreed, I think it should be "depends on LEDS_CLASS" rather than select
> it if there is a hard dependency that cannot be fixed with extracting the
> led support in the driver to #ifdef CONFIG_LEDS_CLASS code.

The led support could be #ifdef CONFIG_LEDS_CLASS, the problem with that
approach is the whole module versus build-in thing:

led-class	shark		enable-led-support
build-in	build-in	yes
build-in	module		yes
module		build-in	no
module		module		yes

Now this can be coded into #ifdef magic, but it won't be pretty,
of course we only need the non pretty version once at the top
to set a SHARK_USE_LEDS define, but still.

I'm fine with either solution (depends or ifdef magic), although
I think that people will get unpleasantly surprised if they want
to use the shark driver and they don't get to see it in the
menu because they don't have leds enabled.

Regards,

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