linux-kernel - Re: [PATCH 22/22] bitops: remove minix bitops from asm/bitops.h

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:	Fri, 15 Oct 2010 22:15:20 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Mike Frysinger <vapier.adi@...il.com>
Cc:	Akinobu Mita <akinobu.mita@...il.com>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 22/22] bitops: remove minix bitops from asm/bitops.h

On Friday 15 October 2010 20:53:16 Mike Frysinger wrote:
> > You have defined these as "native endian":
> >
> > always LE:
> >        alpha, blackfin, ia64, score, tile, x86
> >
> > always BE:
> >        h8300, microblaze, s390, sparc
> >
> > configurable:
> >        m32r, mips, sh, xtensa
> >
> > The only ones among these that possibly ever cared about mounting minix
> > file systems on a big-endian kernel are really old sparc and mips systems,
> > everyone else probably never noticed their mistake.
> >
> > I'd say let's define the minix bitops as always LE and be done with it.
> 
> or at least make it so that this is the default, and you only have to
> update Kconfig if you need to deviate from the default.  i dont like
> having to add this minix option to every single arch Kconfig.

Yes, that would also work if we find a compelling reason to keep it that
way. You can actually keep it private to fs/minix/Kconfig by writing it
as

config MINIX_FS_NATIVE_ENDIAN
	def_bool y
	depends on H8300 || M32R || MICROBLAZE || MIPS || S390 || SUPERH || SPARC || XTENSA

We normally use select for arch specific options, but in this case I think
I would prefer the single option since we know we don't want new architectures
to do it too.

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