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:	Fri, 15 Mar 2013 08:33:44 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	arnd@...db.de
Cc:	geert@...ux-m68k.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, isdn@...ux-pingi.de,
	netdev@...r.kernel.org, dhowells@...hat.com
Subject: Re: [PATCH] isdn: hisax: netjet requires VIRT_TO_BUS

From: Arnd Bergmann <arnd@...db.de>
Date: Fri, 15 Mar 2013 12:29:52 +0000

> On Friday 15 March 2013, David Miller wrote:
>> I do not want to see us add such a Kconfig dependency knob.
>> 
>> Then the real tendency will exist to make new drivers little-endian
>> only, refuse to fix endian-broken old drivers, etc.
>> 
>> Which means that allmodconfig on my architecture will have build
>> coverage on less code, which is really the only thing that matters
>> for me.  I want all drivers that could be effected by my changes
>> to be compile testable on as many platforms as possible.
> 
> There are two separate issues here. The first one that David Howells
> brought up was ill-defined __BIG_ENDIAN/__LITTLE_ENDIAN macros.
> Using CONFIG_CPU_IS_BIG_ENDIAN/CONFIG_CPU_IS_LITTLE_ENDIAN in the code
> is what Linus suggested as a replacement, although I see little
> incentive to do mass conversion there, it would be mainly for new
> code.
> 
> The other issue is the Kconfig logic where Geert would replace
> all the instances of "depends on BROKEN || !(SPARC || PPC || PARISC ||
> M68K || (MIPS && !CPU_LITTLE_ENDIAN) || FRV || (XTENSA &&
> !CPU_LITTLE_ENDIAN))" with something that actually reflects what
> we mean. I think it would be a nice cleanup, but I can also understand
> your hesitation there.
> 
> Do you object to both uses of that symbol, or just to using it in order
> to disable drivers in Kconfig? I don't care too much right now, since
> nothing is actually broken at the moment, I would just like to get
> the VIRT_TO_BUS patch merged so people can also build allmodconfig
> on my architecture ;-)

The first usage seems reason, but the temtation is going to be quite
strong to misuse to block out drivers when there is "no value" in
spending time necessary to simply make them endian clean instead.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists