[ltt-dev] LTTng kernel integration roadmap, update

[Andrew Morton]

On Tue, 25 Nov 2008 12:59:37 -0500 Theodore Tso <tytso at mit.edu> wrote:

> 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

^^ good start!

> 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.
> 

I think when you add in internationalisation, they _are_ insurmountable
problems.  I don't think that full-on shipping of userspace-ready
applications by the kernel team will prove practical.

But let's look at the problem which we're actually trying to solve. 
Developer A wishes to write some kernel monitoring/controlling code, so
he is forced to stick it on his website, keep reminding people to
download updates, act as an independent target of other people's
patches, etc, etc.  It's all a pain and horror, so developer A gives up
and implements his userspace code in the kernel instead.  It is, as a
result, technically inferior and English-only, but at least it got
there.

So I'd propose that userspace/foo/ be viewed as a code *development*
location, not a *delivery* location.  Once a tool has reached a
sufficient level of maturity, stability and usefulness then it's time
to ask the util-linux people "please take this", then remove it from
the kernel tree.  Or to create a separate package altogether, and to
remove the original from the kernel tree.

So userspace/foo/ doesn't have to be *fancy*.  It's a three- to twelve-
month thing where code can sit while kernel developers evolve it.  Its
main consumers at that time will be kernel developers and testers.