From: Theodore Tso <tytso@mit.edu>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
Christoph Hellwig <hch@infradead.org>,
ltt-dev@lists.casi.polymtl.ca, Zhaolei <zhaolei@cn.fujitsu.com>,
Lai Jiangshan <laijs@cn.fujitsu.com>, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: LTTng kernel integration roadmap, update
Date: Tue, 25 Nov 2008 12:59:37 -0500 [thread overview]
Message-ID: <20081125175937.GA525@mit.edu> (raw)
In-Reply-To: <20081125154011.GA4883@uranus.ravnborg.org>
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
next prev parent reply other threads:[~2008-11-25 18:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-24 11:28 LTTng kernel integration roadmap, update Mathieu Desnoyers
2008-11-24 11:41 ` Christoph Hellwig
2008-11-24 12:20 ` Mathieu Desnoyers
2008-11-24 16:58 ` Steven Rostedt
2008-11-24 20:46 ` [ltt-dev] " Mathieu Desnoyers
2008-11-25 7:09 ` Mathieu Desnoyers
2008-11-25 13:57 ` Andrew Morton
2008-11-25 15:40 ` Sam Ravnborg
2008-11-25 17:59 ` Theodore Tso [this message]
2008-11-25 19:09 ` Andrew Morton
2008-11-25 19:30 ` Sam Ravnborg
2008-11-28 12:56 ` [ltt-dev] " Mathieu Desnoyers
2008-11-28 12:58 ` Mathieu Desnoyers
2008-11-25 8:24 ` Christoph Hellwig
2008-11-25 8:47 ` [ltt-dev] " Mathieu Desnoyers
2008-11-25 8:57 ` Theodore Tso
2008-11-25 8:59 ` Christoph Hellwig
2008-12-04 3:49 ` Lai Jiangshan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081125175937.GA525@mit.edu \
--to=tytso@mit.edu \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ltt-dev@lists.casi.polymtl.ca \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=sam@ravnborg.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=zhaolei@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox