Linux-Sparc ext2 compatibility?

Theodore Y. Ts'o (
Tue, 20 Aug 1996 22:48:55 -0400

If you look in /usr/src/linux/asm-sparc/bitops.h, you'll see definitions
of set_bit() and ext2_set_bit(). The definitions of ext2_set_bit() are
designed so that if they are used, an ext2 filesystem created on a Sparc
will be compatible with an ext2 filesystem created on a i386 or Alpha
box. set_bit(), in contrast, is written to be as fast as possible on a
sparc, and is appropriate where cross platform compatibility of how the
bitmask is stored isn't an issue.

There's only one problem --- the ext2 filesystem code is using set_bit(),
and not ext2_set_bit(). And in the e2fsprogs code, the bitops functions
which are used when we are compiling on a sparc are incompatible with
the i386 bitops functions. (As a result, e2fsprogs on a Sparc will fail
most of the e2fsck regression tests, since the filesystem formats are

This is bad --- very bad. It means that you can't take a ext2 floppy
and use it as an interchange mechanism between a Sparc Linux box and a
i386 Linux box. It means you can't just say, "This external 1GB scsi
disk has an ext2 filesystem on it". You have to qualify it with whether
it is a Sparc ext2 filesystem or a i386 ext2 filesystem. This is *not*
the case, for example, with the MSDOS filesystem, which is readable on
any Windows NT machine (i386, Alpha, PPC), or with the BSD UFS
filesystem, which is readable across a wide range of platforms.

The question now is --- how do we fix this? Are there enough Sparc
Linux boxes out there that it's too late to do a flag day? Do we need
to put a lot of complexity into the kernel code and the e2fsprogs
utilities so that we can recognize different versions of the bitmasks
and do the appropriate byte swapping on the bitmasks? (This can be
done, but at some performance cost).

Or, we could decide that we don't care, and just simply leave things in
an incompatible state. That would be a real shame though, I think.

- Ted