[Tux3] Organization of files for kernel port

[Daniel Phillips]

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
Tux3 at tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3