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: <201010151253.15653.arnd@arndb.de>
Date:	Fri, 15 Oct 2010 12:53:15 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Akinobu Mita <akinobu.mita@...il.com>
Cc:	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, Akinobu Mita wrote:
> minix bit operations are only used by minix filesystem and useless
> by other modules.

Right.
 
> This provides new config option CONFIG_MINIX_FS_LITTLE_ENDIAN and
> CONFIG_MINIX_FS_NATIVE_ENDIAN that each architecture selects one of which.
> Then we can remove minix bit operations from asm/bitops.h from all
> architectures by making them minix filesystem local macros.

I would say that any architecture that defines minix bitops as
little-endian is broken and we should not even need the #define.

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.

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ