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 go.
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 that fit. 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 __kernel. For iattr.c, for example, we can have user/iattr.c that just includes user/kernel/iattr.c. 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. Regards, Daniel _______________________________________________ Tux3 mailing list [email protected] http://tux3.org/cgi-bin/mailman/listinfo/tux3
