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: <alpine.LFD.0.999.0709181408390.16478@woody.linux-foundation.org>
Date:	Tue, 18 Sep 2007 14:14:28 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Luis R. Rodriguez" <mcgrof@...il.com>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jeff Garzik <jeff@...zik.org>,
	"John W. Linville" <linville@...driver.com>,
	linux-wireless <linux-wireless@...r.kernel.org>
Subject: Re: [PATCH] Clarify pci_iomap() usage for MMIO-only devices



On Tue, 18 Sep 2007, Luis R. Rodriguez wrote:
> 
> ACK but do we really need to benchmark this if we *know* we are
> creating unnecessary branches? How about Jeff's suggestion of
> introducing pci_mmio_map() ?

Here's the counter-argument:

 - the run-time expense of this is basically *zero*

 - the expense of badly written drivers is absolutely *huge*

The fewer "clever" interfaces we have for no good reason, and the less 
unnecessary stuff that really doesn't matter, the more we help the 
*second* case.

The fact is, for device drivers, the *true* performance issues are nowhere 
*near* the actual IO accessor functions, and are all at a much higher 
level for all but a very very limited set of drivers. And I think you're 
making the important issues *worse*.

Really. "pci_mmio_map()" may not be a bad interface, but you're simply 
working on entirely the wrong problem. The problem is not an out-of-line 
IO accessor function - the problem is that you're making it even more 
complicated to write drivers.

The whole point of the "iomap()" interface was *never* about making the 
driver interfaces faster. It was about making them *cleaner*. And you're 
screwing that up!

The old situation with SATA drivers that had

	if (iomem)
		writel(..)
	else
		outl(..)

in the cases that needed it (and used hardcoded writel/outl in the cases 
that didn't) was an example of code that "in theory" is faster. But 
dammit, in practice that mattered not one whit, and what iomap() tries to 
do is to attack the _real_ problem we had in that area. 

Which had nothing what-so-ever to do with any branches.

		Linus
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ