> 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.
Or we write a widget for flipping them. We've had a symlink situation like
this already. And Id favour fixing it even if it needs a flag day. After
all everyone is about to download and install rembrandt on their sparc
right 8)
We already have a widget --- it's name is e2fsck. I noticed this
problem because part of my release process involves compiling e2fsprogs
under Solaris (so I can run the regression suite under Purify), and I
noticed that the regression suite was failing.
Then I remembered that I had accepted patches so the Sparc could use
non-standard bitops. I had warned the Sparc community that this was a
long term problem, and they agreed to have separate functions for
ext2_set_bit, et. al. I looked in the 2.0 kernel sources to see if they
were actually in use (so I could correctly configure the e2fsprogs
distribution), and the answer was, unfortunately no.
So the current situation with the upcoming 1.05 e2fsprogs is that if it
is configured on a sparc with --enable-std-bitops, it will use the
standard bitops operations. If you run e2fsck compiled with
--eanble-std-bitops, and force a check, it will automatically take care
of fixing the bitmasks.
If we wanted to be really clever, we could put in some sort of switch so
that e2fsck could notice whether or not the kernel had been compiled
with the broken or the standard bitops functions, and then have it do
the right thing depending on the kernel. Now as long as you have the
updated e2fsck, it doesn't matter when you update the kernel. Just make
sure that when you do update the kernel, you force e2fsck to be run at
the boot-time --- perhaps by sync'ing the disks and doing an *un*clean
shutdown.
On the other hand, we could just make people upgrade the kernel and the
new e2fsck at the same time.
- Ted