[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54155B14.9060809@gmail.com>
Date: Sun, 14 Sep 2014 17:08:36 +0800
From: Chen Gang <gang.chen.5i5j@...il.com>
To: Paul Gortmaker <paul.gortmaker@...driver.com>,
"H. Peter Anvin" <hpa@...or.com>
CC: eparis@...hat.com, paulmck@...ux.vnet.ibm.com,
Geert Uytterhoeven <geert@...ux-m68k.org>,
zhenglong.cai@...c.com.cn, khilman@...aro.org, ak@...ux.intel.com,
mcgrof@...e.com, fabf@...net.be,
"dhowells@...hat.com" <dhowells@...hat.com>, pefoley2@...oley.com,
mgorman@...e.de, biederm@...ssion.com,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>, Jean Delvare <jdelvare@...e.de>
Subject: Re: [PATCH] init/Kconfig: Add ENDIAN attributes for all architectures
using
Hello Maintainers:
Is this patch worthy enough to be applied?
Welcome any ideas, suggestions or completions.
Thanks.
On 09/03/2014 07:47 PM, Chen Gang wrote:
> On 09/02/2014 02:13 PM, Chen Gang wrote:
>> On 9/2/14 13:17, Paul Gortmaker wrote:
>>>
>>> OK, but that was not at _all_ what I thought when looking at this...
>>>
>>> Instead I saw a well intentioned, but perhaps not fully thought out
>>> attempt at fixing a largely irrelevant randconfig/allmodconfig of a
>>> 1990's vintage ISDN driver coming from that x86-only era, built against
>>> an architecture that will never use or support it (microblaze).
>>>
>>> In today's world, we'd probably not accept a new ethernet driver or
>>> filesystem if it was incapable of handling both BE and LE (exception
>>> being SoC ethernet physically bound to one specific CPU, of course.)
>>> So the justification given in the commit log for expanding the scope to
>>> better deal with the stuff found in ISDN and the like was questionable.
>>>
>>
>
> I guess, we are mainly focus on: "Is it worthy enough to add *ENDIAN in
> init/Kconfig?"
>
> It seems really few modules need depend on LE or BE (although I am still
> not quite sure). If it is true, for me, only for architectures, it is
> still worthy enough to let all duplicated *ENDIAN to one place.
>
> If it is still worthy, maybe this patch need be improvement (especially,
> for its comments), so please help check when you have time, thanks.
>
>
> Welcome any other members' ideas, suggestions, or completions.
>
> Thanks.
>
>> After a simple search, for crypto, it may be endian sensitive, and for
>> architectures may be endian sensitive, in config time.
>>
>> bash-3.2# find ./ | grep Kconfig | xargs grep depend | grep ENDIAN
>> .//arch/arm/mm/Kconfig: depends on ARCH_SUPPORTS_BIG_ENDIAN
>> .//arch/arm/mm/Kconfig: depends on CPU_BIG_ENDIAN
>> .//arch/arm/mm/Kconfig: depends on CPU_BIG_ENDIAN
>> .//arch/arm64/Kconfig: depends on OF && !CPU_BIG_ENDIAN
>> .//arch/mips/Kconfig: depends on SYS_SUPPORTS_BIG_ENDIAN
>> .//arch/mips/Kconfig: depends on SYS_SUPPORTS_LITTLE_ENDIAN
>> .//arch/mips/Kconfig: depends on SGI_IP22 || SGI_IP28 || (SNI_RM && CPU_LITTLE_ENDIAN)
>> .//arch/powerpc/platforms/Kconfig.cputype: depends on !CPU_LITTLE_ENDIAN
>> .//arch/powerpc/platforms/Kconfig.cputype: depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN
>> .//arch/powerpc/platforms/Kconfig.cputype: depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN
>> .//arch/powerpc/platforms/Kconfig.cputype: depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN
>> .//arch/powerpc/platforms/Kconfig.cputype: depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN
>> .//arch/powerpc/platforms/Kconfig.cputype: depends on CPU_LITTLE_ENDIAN
>> [...]
>> .//crypto/Kconfig: depends on ARM && KERNEL_MODE_NEON && !CPU_BIG_ENDIAN
>> .//crypto/Kconfig: depends on ARM && KERNEL_MODE_NEON && !CPU_BIG_ENDIAN
>> .//drivers/crypto/Kconfig: depends on PPC64 && IBMVIO && !CPU_LITTLE_ENDIAN
>> [...]
>>
>> It is a simple search, so I am not sure whether have other modules also
>> need LE or BE.
>>
>
> Thanks.
>
--
Chen Gang
Open share and attitude like air water and life which God blessed
--
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