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-next>] [day] [month] [year] [list]
Date:	Sat, 12 Dec 2009 13:55:40 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Dave Airlie <airlied@...ux.ie>, Jean Delvare <jdelvare@...e.de>
Cc:	Jeff Mahoney <jeffm@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fb/intelfb: Do not depend on EMBEDDED

Right, the logic is that the driver really is for embedded (i.e. very special purpose) use.  It should not be selected unless you really know what you're doing or are building a very particular product.

If you can think of a better way of preventing users and distros from accidentally selecting this, then please send a patch.

Jesse

Dave Airlie <airlied@...ux.ie> wrote:

>
>> I am worried that the intelfb driver depends on EMBEDDED. I consider
>> this an abuse of the EMBEDDED configuration option, which as I
>> understand it was originally meant to expose fine-tuning options,
>> rather than to arbitrarily disable drivers when not selected.
>
>Since we merged a kms driver for Intel hw that supports all intel chipsets
>and more importantly all the outputs on Intel chipsets, intelfb should
>be considered legacy at the least and broken on > 50% of intel hw.
>
>We left it in in that most ppl who wanted it were using it in embedded 
>configs, whereas for most users it just doesn't work, like I don't thinkit
>supports LVDS which means loading it on a laptop will trash it.
>
>Dave
>
>
>> 
>> So I suggest that we drop this dependency now.
>> 
>> Signed-off-by: Jean Delvare <jdelvare@...e.de>
>> Cc: Jesse Barnes <jbarnes@...tuousgeek.org>
>> Cc: Dave Airlie <airlied@...ux.ie>
>> ---
>> Jesse, in the original commit, you wrote that intelfb was "really a
>> special purpose embedded driver". It looks like a perfectly standard
>> framebuffer driver to me, which means that it may have users beyond
>> embedded. For example I always prefer framebuffer over X for my
>> servers. Or am I missing something and intelfb is really special?
>> 
>>  drivers/video/Kconfig |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> --- linux-2.6.32.orig/drivers/video/Kconfig	2009-12-03 08:48:34.000000000 +0100
>> +++ linux-2.6.32/drivers/video/Kconfig	2009-12-11 10:57:43.000000000 +0100
>> @@ -1121,7 +1121,7 @@ config FB_CARILLO_RANCH
>>  
>>  config FB_INTEL
>>  	tristate "Intel 830M/845G/852GM/855GM/865G/915G/945G/945GM/965G/965GM support (EXPERIMENTAL)"
>> -	depends on EXPERIMENTAL && FB && PCI && X86 && AGP_INTEL && EMBEDDED
>> +	depends on EXPERIMENTAL && FB && PCI && X86 && AGP_INTEL
>>  	select FB_MODE_HELPERS
>>  	select FB_CFB_FILLRECT
>>  	select FB_CFB_COPYAREA
>> 
>> 
>

Powered by blists - more mailing lists