[Tux3] Endian conversions done, probably

Daniel Phillips phillips at phunq.net
Thu Nov 13 14:43:34 PST 2008

Thanks to a lot of hard work from Hirofumi and some help from sparse,
we got all the endian conversions done, it looks like.  It is a crying
shame that gcc cannot do these conversions for us, this is a huge
use of time for many projects and really hurts readability.  Maybe we
should get on the gcc devel list about it.

Ah, bitmap bit order needs to be reversed to allow word-wise bitmap
scanning optimizations.  One more thing.

Anyway, it is time to consider where to go next.  Here are the big

 - Kernel port
 - Atomic update
 - SMP locking

Each of these is a good sized project.  We are almost at the end of
what is more convenient to do in user space than kernel.  To develop
locking code in userspace we would have to do threading and use user
space locks that are quite different from kernel locks, so that looks
like duplication of effort.  Better to go straight to kernel for that.
Atomic updating is heavily dependent on asynchronous IO, which is done
in a very different style in userspace (aio) than in kernel.  It is
actually a lot simpler in kernel.  We can however work out most of the
logging code in userspace, including log commit block format and cache
reconstruction.  This is probably worth doing.

We could do a ready-only kernel port right now, and maybe we should,
just to get the kernel work moving.  I am guessing that it will be
practical to maintain some of our files identically between user space
and kernel, and some will change too much for that.  We will continue
to maintain the user space code even when primarily working on the
kernel, because it will form the basis of our user space utilities,
for example fsck.  I don't think it is useful to maintain the user and
kernel code in the same repository, instead we can try to keep the
common files from diverging by diffing and porting changes between two
repositories.  Kernel maintainers really want Git repositories, while
we seem to be happy with Mercurial.  Solution: kernel code in Git, user
space code in Mercurial, as we already have it.

There are various small issues needing cleaning up, here is my current

 - Filemap does not handle extent that overlaps end of block transfer range
 - Filemap doesn't handle extent overlapping beginning properly either
 - Xattr treats empty xattr as not present, but empty xattrs must be allowed
 - Xattr adds xcache to inode even when there are no xattrs
 - Change bitmap order to big endian
 - unstub free_block in btree.c
 - add owner attributes

I am sure I missed some.  Anyway, it is not a long list, so the time to
to start moving into kernel is pretty close, if not already here.



Tux3 mailing list
Tux3 at tux3.org

More information about the Tux3 mailing list