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: <20070517102931.6bbbad1a.akpm@linux-foundation.org>
Date:	Thu, 17 May 2007 10:29:31 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	dedekind@...radead.org
Cc:	linux-kernel@...r.kernel.org, Christoph Hellwig <hch@....de>
Subject: Re: [PATCH] ubi: kill homegrown endian macros

On Thu, 17 May 2007 18:09:50 +0300 Artem Bityutskiy <dedekind@...radead.org> wrote:

> On Thu, 2007-05-17 at 16:56 +0200, Christoph Hellwig wrote:
> > On Thu, May 17, 2007 at 05:50:43PM +0300, Artem Bityutskiy wrote:
> > > Christoph,
> > > 
> > > On Thu, 2007-05-17 at 16:32 +0200, Christoph Hellwig wrote:
> > > > Kill ubis homegrown endianess handling crap and replace it with
> > > > the normal kernel endianess handling.
> > > 
> > > Err,__be32 and the company are just sparse things, while I have compiler
> > > checks with my struct ubi32_t and friends. JFFS2 also uses the same
> > > technique. Why do you force me to rely on sparse instead instead of
> > > compiler?
> > 
> > Yes.  Like all other code in the kernel aswell.
> 
> Andrew, may I please have your ack that I absolutely have to use __be32
> instead of my own types since Christoph tends to provide no explanation
> to his requests.

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).

So I wouldn't be averse to creating a new, generic, kernel-wide alternative
to the existing __be32/__le32/etc code.  It is an improvement.

But I don't think we want driver-private implementations.

We could conceivably simply switch the existing stuff to use structs, but
quite a lot of code assumes that cpu_to_foo32(0) == 0 and just does
open-coded assigments of zero.  They'd need fixups.
-
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/