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]

Message-ID: <20120427165306.GC14743@mudshark.cambridge.arm.com>
Date:	Fri, 27 Apr 2012 17:53:06 +0100
From:	Will Deacon <will.deacon@....com>
To:	Mike Frysinger <vapier@...too.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"uclinux-dist-devel@...ckfin.uclinux.org" 
	<uclinux-dist-devel@...ckfin.uclinux.org>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 1/2] asm-generic: io: remove {read,write} string functions

Hi Mike,

On Fri, Apr 27, 2012 at 05:17:47PM +0100, Mike Frysinger wrote:
> On Friday 27 April 2012 06:42:55 Will Deacon wrote:
> > The {read,write}s{b,w,l} functions are not defined across all
> > architectures and therefore shouldn't be used by portable drivers. We
> > should encourage driver writers to use the io{read,write}{8,16,32}_rep
> > functions instead.
> 
> well, that isn't true today as a grep of the drivers/ tree shows.  perhaps we 
> should fix that first ?  quite a number of architectures do implement these.

Sure, and architectures can continue to implement these if they're using
drivers that require them (I'll reintroduce them for blackfin). They
shouldn't be used for new architectures though, so any drivers that are
required by folks using asm-generic/io.h will need converting.

> > This patch removes the {read,write} string functions for the generic IO
> > header as they have no place in a new architecture port.
> 
> i don't see any file anywhere that describes what the baseline API is supposed 
> to be, and what each set of funcs are for.  there is just the random ugliness 
> in each arch's asm/io.h cobbled together until things work.  i think that also 
> needs to be addressed before we go extending/contracting the API provides by 
> asm-generic/io.h.

I agree that it's a bit of a mess, but if we can keep the asm-generic
interfaces clean then it can help driver writers see what we have as a
common base. If a driver is not portable (maybe for some
architecture-specific device) then they could use extra accessors if they
really need to.

The point of removing these functions is to make it clear that they're not
part of the baseline API and instead encourage people to use other accessors
instead if they want to write portable code.

Will
--
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/