linux-kernel - Re: [PATCH 1/2] asm-generic: io: remove {read,write} string functions

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, 27 Apr 2012 19:26:11 -0400
From:	Mike Frysinger <vapier@...too.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Will Deacon <will.deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"uclinux-dist-devel@...ckfin.uclinux.org" 
	<uclinux-dist-devel@...ckfin.uclinux.org>
Subject: Re: [PATCH 1/2] asm-generic: io: remove {read,write} string functions

On Friday 27 April 2012 16:52:34 Arnd Bergmann wrote:
> On Friday 27 April 2012, H. Peter Anvin wrote:
> > On 04/27/2012 10:14 AM, Will Deacon wrote:
> > > If you remove the architecture-specific drivers, there's really not a
> > > lot left and, even then, we only need to convert those drivers which
> > > are intended to be portable between architectures where the string
> > > functions are not consistently available.
> > > 
> > > By overheads, I assume you're referring to the IO_COND check on the
> > > address space? I wouldn't expect this to be noticeable compared to the
> > > cost of the I/O access and I'm not sure it's worth worrying about for
> > > the sake of the small number of drivers affected.
> > 
> > It's not in time, but it adds bulk to the code.  The point is that what
> > is the benefit of not making these part of the general API?  For
> > architectures where the address space doesn't matter they could just
> > alias it to the same functions, or use the generic versions.
> 
> The main reasons I can see for not making it a general purpose API are:
> 
> * It's a very confusing interface, because the endianess rules are
> different from the non-string variants and counterintuitive.
> 
> * Almost all the users are ancient ARM specific drivers, the others are
>   either new ARM specific drivers or drivers that started out as ARM-only
>   and were ported later to other architectures (sh, avr32, mips, mn10300
>   and blackfin)
> 
> * On all these architectures, the PCI I/O space is memory mapped (or
>   non-existent), so the ioread* functions are trivial wrappers without
>   additional overhead.
> 
> * Most architectures don't implement them today, but all architectures
>   that support MMIO also implement the ioread string operations.

i'm ambivalent with keeping or tossing these funcs.  Blackfin (afaik) picked 
them up really only for the reasons Arnd cited -- drivers using memory mapped 
registers originally for ARM (or m68k/coldfire i think) used this API, and it 
was easier for us to implement these defines in our asm/io.h and get the 
drivers "for free".

i am strongly in favor though of agreeing on & documenting the baseline API 
first before attempting to clean anything up.  sorry to keep harping on this.
-mike

Download attachment "signature.asc " of type "application/pgp-signature" (837 bytes)