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 items: - 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 list: - 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. Regards, Daniel _______________________________________________ Tux3 mailing list [email protected] http://tux3.org/cgi-bin/mailman/listinfo/tux3
