[Tux3] Organization of files for kernel port

[Daniel Phillips]

On Sunday 16 November 2008 05:09, Martin Steigerwald wrote:
> 
> Hi Daniel,
> 
> Am Samstag 15 November 2008 schrieb Daniel Phillips:
> > 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.
> 
> Just a naive question from me - I didn't do much more than adjusting a 
> kernel patch, tuxonice usually, to apply cleanly till now and just lurked 
> in the background being curious about tux3 and fs developments in 
> general:
> 
> How about having
> 
> - userspace for userspace only stuff
> - common for stuff that can be common to both worlds
> - kernel for kernel only stuff
> 
> as directories and placing files accordingly? This would seem to be the 
> cleanest classification to me.

The kernel patch has to include all the files involved in the kernel
build, it is not ok to have some in a separate tree.  It is also not ok
to put the user space files in the kernel tree.  So there can be common
files, but they have to be copies, they can't be a shared directory.

We have more flexibility in how we organize the user space code.  So
one of the directories is indeed a "common" directory, which is named
"kernel".

In general, trying to keep files identical between kernel and user
space is a losing battle because there are multiple kernel versions,
with interfaces changing over time.  For now, we are able to get some
advantage from having common files because we will stay with the same
kernel version until the first port is basically working.  After that,
the difficulty of keeping files from diverging will increase, and the
importance will decrease, because less work will be being done in user
space, where performance doesn't matter and there is no parallelism, so
there is no such thing as locking.  Instead of having common files, we
will rely on a common file format, and have just a handful of common
files like dleaf.c that have their own api and don't interface directly
with the kernel.  These files can be kept up to date by copying without
much effort.

Regards,

Daniel

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3