>> 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).
Tom> We should have a flag day. There aren't that many Linux/SPARC
Tom> machines right now as compared to the Intel port and the people
Tom> running existing systems understand that the SPARC port is just
Tom> coming out of the "hackers" stage. These people would understand
Tom> if a major change had to be instituted. There was a previous
Tom> problem with ext2 symlinks that called for a flag day.
As David explained this is not really a Sparc problem, but rather a
m68k problem. The problem is just the fact that the m68k port is not
just coming out of the 'hacker' stage, I for once started playing
with Linux on my Amiga more than 3 years ago and was not even there
when the whole m68k thing started. Besides we still have some users who
refuse to upgrade their kernels from the old 0.9.x ones, because the
filesystem was for the m68k changed somewhere in the 1.2.13 days.
Tom> If we worried about backward compatibility when something is
Tom> obviously broken, then Linux would have not gotten to where it is
Tom> today (all ports).
Why is it obviously broken? UFS supports both big-endian and
little-endian filesystems, this is an option for the ext2 filesystem
as well.
Jes