linux-kernel - Re: [PATCH] ubi: kill homegrown endian macros

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.DEB.0.99.0705172254560.27207@sigma.j-a-k-j.com>
Date:	Thu, 17 May 2007 22:57:48 -0400 (EDT)
From:	"John Anthony Kazos Jr." <jakj@...-k-j.com>
To:	David Woodhouse <dwmw2@...radead.org>
cc:	Matthieu CASTET <castet.matthieu@...e.fr>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ubi: kill homegrown endian macros

On Fri, 18 May 2007, David Woodhouse wrote:
> On Thu, 2007-05-17 at 20:30 +0000, Matthieu CASTET wrote:
> > On Thu, 17 May 2007 10:29:31 -0700, Andrew Morton wrote:
> > 
> > > On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy
> > > <dedekind@...radead.org> wrote:
> > > 
> > > umm..  I'd say what you've done in there is an improvement to the
> > > exiting stuff: getting gcc to check it is better than having to use
> > > sparse.
> > > 
> > > I'd have expected gcc to generate poorer code with your approach but I'm
> > > showing zero text size changes from Christoph's patch (gcc-4.1 and
> > > gcc-3.4.5).
> > > 
> > >
> > On which arch did you try ?
> > X86 where unaligned access are ok ?
> > 
> > On arch that don't support aligned access, packed struct access will be 
> > done byte per byte (but it could be the expected behavior if there 
> > unaligned access).
> 
> When I tested this on ARM, the output for je32_to_cpu et al was fine.
> For _other_ structures where I'd used __attribute__((packed)) to be
> safe, gcc would emit code to handle unaligned loads. But not in the
> simple case where the struct has only one member.
> 
> Are you suggesting that this has changed since I did my testing?

Wouldn't the appropriate test be to demonstrate that the same program text 
opcodes are generated in both cases for all architectures? If that's not 
the case, even if the generation isn't -worse-, it shows that the compiler 
is doing different things with each, which means different versions of the 
compiler could do different things with it, and all of a sudden another 
nice programming construct which helps compile-time issues ends up 
increasing the number of cases where compiler differences generate faster 
or slower kernels with the same code, whereas in the test cases it was "no 
better, no worse" so deemed fine.
-
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/