lkml.org 
[lkml]   [1996]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectLinux-Sparc ext2 compatibility?

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

    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

    \
     
     \ /
      Last update: 2005-03-22 13:38    [W:7.388 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site