[Tux3] Organization of files for kernel port
phillips at phunq.net
Fri Nov 14 23:50:08 PST 2008
It's time... even though there is stil much we can do in user space, we
need to get going on kernel coding sooner or later, so today might as
well be the day. To be sure, we will continue the user space
development too. There are a bunch of things we can best develop in
userspace, where we have valgrind and the code builds an order of
magnitude faster. But some very important pieces can only be done
practically in the for-real kernel. Locking, for example. So here we
One thing we are going to try to do is to make at least some files
identical between kernel and user space. This will work particularly
well for files like dleaf.c, ileaf.c, iattr.c and xattr.c that are just
bashing information structures. There will be a few adjustments to
make, for example sometimes the kernel supports similar library calls
with slightly funky argument order. But in general this should not be
too painful. We will take those files into kernel, edit them to
compile, then take the diffs back into the user space code and make
All the files that are identical between kernel and user space will go
in a new "kernel" directory. Most but not all of tux3.h can be used in
kernel. If we avoid putting anything kernel-specific in it, then we
can have tux3.h in the main user code directory that includes
kernel/tux3.h, then has userspace-specific content. If tux3.h
unavoidably had to have kernel content, it can be set off with #ifdef
For iattr.c, for example, we can have user/iattr.c that just includes
For the time being, we will do some things like #define printf printk,
and disable the kernel warnings on C99-style inline declarations. At
some point we will go through and scrub away all such non-Linus style,
but at this point it would just be distracting.
There may be a few files that have just a few small differences between
kernel and user space. We might consider using patch to take care of
those differences and have a script that pulls hacked files out of
kernel patches them for user space, and vice versa. I don't know, this
kind of scheme can get clunky, but it's another tools we could use.
We can also move the tux3 user code a little closer to kernel style.
For example, inode->sb becomes inode->i_sb. A little uglier, but sigh.
I think we will wrap all buffer operations with inlines to avoid
damaging our eyes with the ugly, ancient kernel buffer handling style.
I hope to get rid of kernel buffers one day anyway, so that is an
argument for wrapping all access now. Another is, buffer_head->data is
char * in kernel, which is dumb. Our buffer_data(buffer) will be void
*, more sensible and eliminating lots of ugly, disruptive casts.
Any suggestions for further easing the transition welcome.
Tux3 mailing list
Tux3 at tux3.org
More information about the Tux3