[ltt-dev] LTTng kernel integration roadmap, update

[Theodore Tso]

On Tue, Nov 25, 2008 at 04:40:11PM +0100, Sam Ravnborg wrote:
> > 
> > Mathieu, if you're feeling keen I'd suggest that you just type `mkdir
> > -p userspace/lttng' and build your userspace tools in there.
> 
> Maybe this can help...
> 
> 	Sam
> 
> diff --git a/usr/lttng/Makefile b/usr/lttng/Makefile
> new file mode 100644
> index 0000000..8667998
> --- /dev/null
> +++ b/usr/lttng/Makefile
> @@ -0,0 +1,4 @@
> +
> +always := ltt
> +
> +hostprogs-y := ltt

hostprogs are intended to be run on the host during the compilation
process, right?  What we really want is something that allows us to
build userspace programs intended for use on the target, not the host,
since they aren't going to be used when the system is compiled, but
when the system is run.

This also brings up some interesting questions such as where would we
install these userspace programs (which could be kernel version
specific), and how they would be packaged.  In some ways, this is
similar to a previously unsolved and unresolved problem with firmware
which people want to move out of the kernel (but not for legal
reasons, they swear, but because most of the time the firmware stays
constant from version to version --- except when it doesn't).

The same arguments that are used for ejecting firmware from the kernel
and not wanting to ship multiple versions of binaries with the kernel
can also be used for these sorts of low-level userspace binaries which
may be kernel version specific which are often duplicated.

I happen to disagree with those who wish to eject firmware from the
kernel sources (because I don't believe it is for technology reasons,
but because they want to be able to chant, "Unclean, Unclean!" as they
type rm -rf firmware).  And I think we should need to be able to
distribute userspace binaries in the kernel, because of the versioning
issues and so we can guarantee that we get upgraded userspace tools
into the hands of users when they upgrade to the latest kernel.org
kernel and need certian updated userspace utilities where we want the
stable kernel interface to be located at a kernel-shipped userspace
program or library.   

However, we do need to understand that there are issues around
building target userspace progs, where they get installed, changing
the kernel packaging systems to include them in the kernel image
package, creating some convention so users can set the appropriate
search path in their shells depending on which kernel they have
booted, etc.  These are not insurmountable problems.  But they are
ones that we need to solve first.

					- Ted