linux-kernel - Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness

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:	Thu, 21 Feb 2008 07:38:40 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	avorontsov@...mvista.com
Cc:	Paul Mackerras <paulus@...ba.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Clemens Koller <clemens.koller@...gramm.de>,
	linux-fbdev-devel@...ts.sourceforge.net, adaplas@...il.com,
	Krzysztof Helt <krzysztof.h1@...zta.fm>,
	linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org,
	Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign
	endianness


On Wed, 2008-02-20 at 15:18 +0300, Anton Vorontsov wrote:
> On Wed, Feb 20, 2008 at 11:56:35AM +1100, Paul Mackerras wrote:
> > Andrew Morton writes:
> > 
> > > Bizarrely, the original author of the patch (Anton) has fallen off the cc. 
> > > Could whoever did that please thwap himself?
> > > 
> > > Anyway, my head is now officially spinning.  Did anyone actually have a
> > > reason why we shouldn't proceed with Anton's patch?
> > 
> > I was wondering if it would be sufficient to provide alternative
> > versions of fb_readl, fb_writel etc. that do byte-swapping.
> 
> This is of course viable alternative. And I was considering this, but
> later I abandoned the idea: that way we'll end up doing math in the
> native endianness and then converting it to the foreign. This feels
> ugly in contrast when we can do the right math in the first place, per
> framebuffer.

Also, the type of swap to do in fb_readl/writel would have to depend
on the bit depth which is kind of ugly.

> > That
> > would mean that all framebuffers would have to have the same
> > endianness,
> 
> Yup, another downside of changing the code to fix some narrow
> problem. Plus, this means things will break if/when we'll attach
> PCI video card into the MPC8360E-RDK.

Right.

Ben.

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