* [Buildroot] [PATCH v5 1/1] ktap: new package
@ 2013-12-10 11:59 Anders Darander
2013-12-10 12:35 ` Peter Korsgaard
0 siblings, 1 reply; 10+ messages in thread
From: Anders Darander @ 2013-12-10 11:59 UTC (permalink / raw)
To: buildroot
Add ktap, a script-based dynamic tracing tool.
Signed-off-by: Anders Darander <anders@chargestorm.se>
---
Changes v4 -> v5:
- Remove trailing whitespace that was added by mistake in
last version.
Changes v3 -> v4:
- Rename patches to start with package name.
- Fix language in Config.in help text. (I.e.
fix typos from ktap README).
- Remove alignment of =
- Use the new github helper to retrieve tarball.
Changes v2 -> v3:
- Fix typo in TARGET_CONFIGURE_OPTS. The typo was added after
building and running on a beaglebone, but prior to pure build
testing on another target. ktap successfully built, but for the
host arch...
No update to ktap v0.4, as this will require more configure options
to get a deterministic build. I'll update to v0.4 as soon as my
schedule allows me some time for testing.
Changes v1 -> v2:
- Change {} to () around e.g. LINUX_VERSION_PROBED
- Use TARGET_CONFIGURE_OPTS instead of setting CC
- Explicitly install to file instead of directory
- Add depends on BR2_TOOLCHAIN_HAS_THREADS
package/Config.in | 1 +
package/ktap/Config.in | 26 ++++++++++++++++++++
...p-0001-interpreter-vm.c-include-uaccess.h.patch | 27 +++++++++++++++++++++
package/ktap/ktap-0002-Set-PWD-in-Makefile.patch | 28 ++++++++++++++++++++++
package/ktap/ktap.mk | 25 +++++++++++++++++++
5 files changed, 107 insertions(+)
create mode 100644 package/ktap/Config.in
create mode 100644 package/ktap/ktap-0001-interpreter-vm.c-include-uaccess.h.patch
create mode 100644 package/ktap/ktap-0002-Set-PWD-in-Makefile.patch
create mode 100644 package/ktap/ktap.mk
diff --git a/package/Config.in b/package/Config.in
index aa928ec..40c9e31 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -50,6 +50,7 @@ source "package/duma/Config.in"
source "package/gdb/Config.in"
source "package/iozone/Config.in"
source "package/kexec/Config.in"
+source "package/ktap/Config.in"
source "package/latencytop/Config.in"
source "package/lmbench/Config.in"
if BR2_PACKAGE_BUSYBOX_SHOW_OTHERS
diff --git a/package/ktap/Config.in b/package/ktap/Config.in
new file mode 100644
index 0000000..43195df
--- /dev/null
+++ b/package/ktap/Config.in
@@ -0,0 +1,26 @@
+config BR2_PACKAGE_KTAP
+ bool "ktap"
+ depends on BR2_LINUX_KERNEL
+ depends on BR2_TOOLCHAIN_HAS_THREADS
+ help
+ ktap is a script-based dynamic tracing tool for Linux
+
+ It uses a scripting language and lets users trace the Linux kernel
+ dynamically. ktap is designed to give operational insights with
+ interoperability that allows users to tune, troubleshoot and extend
+ kernel and application. It's similar to Linux Systemtap and
+ Solaris Dtrace.
+
+ ktap doesn't support kernels older than 3.1.
+
+ Your kernel must have CONFIG_EVENT_TRACING,
+ CONFIG_PERF_EVENTS, and CONFIG_DEBUG_FS enabled to compile.
+
+ http://www.ktap.org
+
+comment "ktap requires a linux kernel to be built"
+ depends on !BR2_LINUX_KERNEL
+
+comment "ktap needs a toolchain w/ threads"
+ depends on !BR2_TOOLCHAIN_HAS_THREADS
+
diff --git a/package/ktap/ktap-0001-interpreter-vm.c-include-uaccess.h.patch b/package/ktap/ktap-0001-interpreter-vm.c-include-uaccess.h.patch
new file mode 100644
index 0000000..c7c6bbe
--- /dev/null
+++ b/package/ktap/ktap-0001-interpreter-vm.c-include-uaccess.h.patch
@@ -0,0 +1,27 @@
+From 343cb5a8b11a1dfdf4262fce326113e889f13496 Mon Sep 17 00:00:00 2001
+From: Anders Darander <anders@chargestorm.se>
+Date: Sat, 9 Nov 2013 23:05:05 +0100
+Subject: [PATCH] interpreter/vm.c: include uaccess.h
+
+otherwise functions, such as copy_from_user, is implicitly defined.
+
+Signed-off-by: Anders Darander <anders@chargestorm.se>
+---
+ interpreter/vm.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/interpreter/vm.c b/interpreter/vm.c
+index bc7b951..f7cb794 100644
+--- a/interpreter/vm.c
++++ b/interpreter/vm.c
+@@ -28,6 +28,7 @@
+ #include <linux/signal.h>
+ #include <linux/sched.h>
+ #include "../include/ktap.h"
++#include <linux/uaccess.h>
+
+ #define KTAP_MINSTACK 20
+
+--
+1.8.4.2
+
diff --git a/package/ktap/ktap-0002-Set-PWD-in-Makefile.patch b/package/ktap/ktap-0002-Set-PWD-in-Makefile.patch
new file mode 100644
index 0000000..e62d4f1
--- /dev/null
+++ b/package/ktap/ktap-0002-Set-PWD-in-Makefile.patch
@@ -0,0 +1,28 @@
+From 90a8dd877b7766b1ba722c19569cffb68625288b Mon Sep 17 00:00:00 2001
+From: Anders Darander <anders@chargestorm.se>
+Date: Mon, 11 Nov 2013 13:04:36 +0100
+Subject: Set PWD in Makefile
+
+When cross-compiling using e.g. buildroot, PWD was not reset in the Makefile.
+That caused PWD to have an incorrect value, and thus building the module failed.
+
+Signed-off-by: Anders Darander <anders@chargestorm.se>
+---
+ Makefile | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/Makefile b/Makefile
+index 372b41a..939d25e 100644
+--- a/Makefile
++++ b/Makefile
+@@ -25,6 +25,7 @@ ktapvm-y := $(INTP_OBJS)
+
+ KVERSION ?= $(shell uname -r)
+ KERNEL_SRC ?= /lib/modules/$(KVERSION)/build
++PWD := $(shell pwd)
+ mod:
+ $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules
+
+--
+1.8.4.2
+
diff --git a/package/ktap/ktap.mk b/package/ktap/ktap.mk
new file mode 100644
index 0000000..a5d277a
--- /dev/null
+++ b/package/ktap/ktap.mk
@@ -0,0 +1,25 @@
+################################################################################
+#
+# ktap, script-based dynamic tracing tool
+#
+################################################################################
+
+KTAP_VERSION = v0.3
+KTAP_SITE = $(call github,ktap,ktap,$(KTAP_VERSION))
+KTAP_SOURCE = v$(KTAP_VERSION).tar.gz
+KTAP_LICENSE = GPLv2
+KTAP_LICENSE_FILES = LICENSE-GPL
+
+KTAP_DEPENDENCIES = linux
+
+define KTAP_BUILD_CMDS
+ $(MAKE) -C $(@D) $(TARGET_CONFIGURE_OPTS) ktap
+ $(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS) KERNEL_SRC=$(LINUX_DIR) KVERSION=$(LINUX_VERSION_PROBED) mod
+endef
+
+define KTAP_INSTALL_TARGET_CMDS
+ $(INSTALL) -D -m755 $(@D)/ktap $(TARGET_DIR)/usr/bin/ktap
+ $(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS) KERNEL_SRC=$(LINUX_DIR) KVERSION=$(LINUX_VERSION_PROBED) modules_install
+endef
+
+$(eval $(generic-package))
--
1.8.5.1
^ permalink raw reply related [flat|nested] 10+ messages in thread* [Buildroot] [PATCH v5 1/1] ktap: new package
2013-12-10 11:59 [Buildroot] [PATCH v5 1/1] ktap: new package Anders Darander
@ 2013-12-10 12:35 ` Peter Korsgaard
2013-12-10 12:55 ` Anders Darander
0 siblings, 1 reply; 10+ messages in thread
From: Peter Korsgaard @ 2013-12-10 12:35 UTC (permalink / raw)
To: buildroot
>>>>> "Anders" == Anders Darander <anders@chargestorm.se> writes:
> Add ktap, a script-based dynamic tracing tool.
> Signed-off-by: Anders Darander <anders@chargestorm.se>
> ---
> Changes v4 -> v5:
> - Remove trailing whitespace that was added by mistake in
> last version.
I just did a little test build with qemu_arm_versatile_defconfig:
/home/peko/source/buildroot/output/build/ktap-v0.3/interpreter/ktap.c:32:6: warning: "CONFIG_EVENT_TRACING" is not defined [-Wundef]
/home/peko/source/buildroot/output/build/ktap-v0.3/interpreter/ktap.c:33:2: error: #error "Please enable CONFIG_EVENT_TRACING before compile ktap"
/home/peko/source/buildroot/output/build/ktap-v0.3/interpreter/ktap.c:36:6: warning: "CONFIG_PERF_EVENTS" is not defined [-Wundef]
/home/peko/source/buildroot/output/build/ktap-v0.3/interpreter/ktap.c:37:2: error: #error "Please enable CONFIG_PERF_EVENTS before compile ktap"
make[3]: *** [/home/peko/source/buildroot/output/build/ktap-v0.3/interpreter/ktap.o] Error 1
It would be good if we could automatically enable the needed kernel
features when ktap is enabled, similar to how we do for E.G. devtmpfs.
But that can be done as a followup patch, so committed - Thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH v5 1/1] ktap: new package
2013-12-10 12:35 ` Peter Korsgaard
@ 2013-12-10 12:55 ` Anders Darander
2013-12-10 13:01 ` Jeremy Rosen
0 siblings, 1 reply; 10+ messages in thread
From: Anders Darander @ 2013-12-10 12:55 UTC (permalink / raw)
To: buildroot
* Peter Korsgaard <jacmet@uclibc.org> [131210 13:35]:
> >>>>> "Anders" == Anders Darander <anders@chargestorm.se> writes:
> > Add ktap, a script-based dynamic tracing tool.
> > Signed-off-by: Anders Darander <anders@chargestorm.se>
> > ---
> > Changes v4 -> v5:
> > - Remove trailing whitespace that was added by mistake in
> > last version.
> I just did a little test build with qemu_arm_versatile_defconfig:
> /home/peko/source/buildroot/output/build/ktap-v0.3/interpreter/ktap.c:32:6: warning: "CONFIG_EVENT_TRACING" is not defined [-Wundef]
> /home/peko/source/buildroot/output/build/ktap-v0.3/interpreter/ktap.c:33:2: error: #error "Please enable CONFIG_EVENT_TRACING before compile ktap"
> /home/peko/source/buildroot/output/build/ktap-v0.3/interpreter/ktap.c:36:6: warning: "CONFIG_PERF_EVENTS" is not defined [-Wundef]
> /home/peko/source/buildroot/output/build/ktap-v0.3/interpreter/ktap.c:37:2: error: #error "Please enable CONFIG_PERF_EVENTS before compile ktap"
> make[3]: *** [/home/peko/source/buildroot/output/build/ktap-v0.3/interpreter/ktap.o] Error 1
> It would be good if we could automatically enable the needed kernel
> features when ktap is enabled, similar to how we do for E.G. devtmpfs.
Sure, that would be an idea.
I could take a look at that, as long as it's OK with everyone that
enabling ktap might change the kernel config. (Though, it'll be pretty
deterministic anyway)...
> But that can be done as a followup patch, so committed - Thanks.
Thanks!
Cheers,
Anders
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH v5 1/1] ktap: new package
2013-12-10 12:55 ` Anders Darander
@ 2013-12-10 13:01 ` Jeremy Rosen
2013-12-10 13:39 ` Peter Korsgaard
0 siblings, 1 reply; 10+ messages in thread
From: Jeremy Rosen @ 2013-12-10 13:01 UTC (permalink / raw)
To: buildroot
>
> > It would be good if we could automatically enable the needed kernel
> > features when ktap is enabled, similar to how we do for E.G.
> > devtmpfs.
>
> Sure, that would be an idea.
>
> I could take a look at that, as long as it's OK with everyone that
> enabling ktap might change the kernel config. (Though, it'll be
> pretty
> deterministic anyway)...
>
> > But that can be done as a followup patch, so committed - Thanks.
>
two remarks
1) the usual problem with that idea is that if the kernel is externally
built, you can't do that (you don't even know if/where the config is)
2) I'd rather have it works similar to other dependancies, i.e having
the option removed and a comment telling me what I need to enable to
have ktap available.
I recently had a similar problem with udev needing inotify, so the
problem of the plumbing layer relying on some specific kernel feature
is probably a more generic problem... maybe a config option telling
kconfig where the kernel is ? That would be tricky with the way
kconfig works, but that would be nice...
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH v5 1/1] ktap: new package
2013-12-10 13:01 ` Jeremy Rosen
@ 2013-12-10 13:39 ` Peter Korsgaard
2013-12-10 14:36 ` Thomas De Schampheleire
0 siblings, 1 reply; 10+ messages in thread
From: Peter Korsgaard @ 2013-12-10 13:39 UTC (permalink / raw)
To: buildroot
>>>>> "Jeremy" == Jeremy Rosen <jeremy.rosen@openwide.fr> writes:
Hi,
> two remarks
> 1) the usual problem with that idea is that if the kernel is externally
> built, you can't do that (you don't even know if/where the config is)
But that's not a problem for ktap, as it can only be used with an
internally built kernel as is.
> 2) I'd rather have it works similar to other dependancies, i.e having
> the option removed and a comment telling me what I need to enable to
> have ktap available.
That's not how we handle the other settings like devtmpfs, cgroups,
EABI, initramfs, .. The kernel has LOTS of options, I don't want to see
Buildroot configuration options for all of them.
> I recently had a similar problem with udev needing inotify, so the
> problem of the plumbing layer relying on some specific kernel feature
> is probably a more generic problem... maybe a config option telling
> kconfig where the kernel is ? That would be tricky with the way
> kconfig works, but that would be nice...
Basically the strategy is:
Do the right thing automatically if BR builds the kernel, and otherwise
the user is on his own (we'll normally document the requirements in the
help text, but there's no logic to detect it)
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH v5 1/1] ktap: new package
2013-12-10 13:39 ` Peter Korsgaard
@ 2013-12-10 14:36 ` Thomas De Schampheleire
2013-12-10 14:42 ` Peter Korsgaard
0 siblings, 1 reply; 10+ messages in thread
From: Thomas De Schampheleire @ 2013-12-10 14:36 UTC (permalink / raw)
To: buildroot
On Tue, Dec 10, 2013 at 2:39 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Jeremy" == Jeremy Rosen <jeremy.rosen@openwide.fr> writes:
>
> Hi,
>
> > two remarks
>
> > 1) the usual problem with that idea is that if the kernel is externally
> > built, you can't do that (you don't even know if/where the config is)
>
> But that's not a problem for ktap, as it can only be used with an
> internally built kernel as is.
>
>
> > 2) I'd rather have it works similar to other dependancies, i.e having
> > the option removed and a comment telling me what I need to enable to
> > have ktap available.
>
> That's not how we handle the other settings like devtmpfs, cgroups,
> EABI, initramfs, .. The kernel has LOTS of options, I don't want to see
> Buildroot configuration options for all of them.
>
>
> > I recently had a similar problem with udev needing inotify, so the
> > problem of the plumbing layer relying on some specific kernel feature
> > is probably a more generic problem... maybe a config option telling
> > kconfig where the kernel is ? That would be tricky with the way
> > kconfig works, but that would be nice...
>
> Basically the strategy is:
>
> Do the right thing automatically if BR builds the kernel, and otherwise
> the user is on his own (we'll normally document the requirements in the
> help text, but there's no logic to detect it)
>
Slightly related to this topic is the inconsistency in the Config.in
comments about needing a kernel. Same say:
'foo needs a Linux kernel to be built'
while others say
'foo needs a Linux kernel'
The first seems to emphasize that we require a Linux kernel to be
built in buildroot, while the second one leaves it in the middle. For
packages that actually build kernel modules, like ktap, we really need
the kernel inside buildroot, right? Are there any packages that depend
on BR2_LINUX_KERNEL that do _not_ require an in-buildroot kernel?
Thanks,
Thomas
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH v5 1/1] ktap: new package
2013-12-10 14:36 ` Thomas De Schampheleire
@ 2013-12-10 14:42 ` Peter Korsgaard
2013-12-10 14:49 ` Thomas De Schampheleire
0 siblings, 1 reply; 10+ messages in thread
From: Peter Korsgaard @ 2013-12-10 14:42 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:
Hi,
> The first seems to emphasize that we require a Linux kernel to be
> built in buildroot, while the second one leaves it in the middle. For
> packages that actually build kernel modules, like ktap, we really need
> the kernel inside buildroot, right? Are there any packages that depend
> on BR2_LINUX_KERNEL that do _not_ require an in-buildroot kernel?
I don't think so, as BR2_LINUX_KERNEL is the symbol to build a linux
kernel internally.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH v5 1/1] ktap: new package
2013-12-10 14:42 ` Peter Korsgaard
@ 2013-12-10 14:49 ` Thomas De Schampheleire
2013-12-10 16:54 ` Arnout Vandecappelle
0 siblings, 1 reply; 10+ messages in thread
From: Thomas De Schampheleire @ 2013-12-10 14:49 UTC (permalink / raw)
To: buildroot
On Tue, Dec 10, 2013 at 3:42 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:
>
> Hi,
>
> > The first seems to emphasize that we require a Linux kernel to be
> > built in buildroot, while the second one leaves it in the middle. For
> > packages that actually build kernel modules, like ktap, we really need
> > the kernel inside buildroot, right? Are there any packages that depend
> > on BR2_LINUX_KERNEL that do _not_ require an in-buildroot kernel?
>
> I don't think so, as BR2_LINUX_KERNEL is the symbol to build a linux
> kernel internally.
Ok, sounds logical.
So what is the best comment text? Simply:
"foo needs a Linux kernel to be built"
?
If we can agree on something I will submit a patch to make this consistent.
Thanks,
thomas
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Buildroot] [PATCH v5 1/1] ktap: new package
2013-12-10 14:49 ` Thomas De Schampheleire
@ 2013-12-10 16:54 ` Arnout Vandecappelle
2013-12-10 20:50 ` Peter Korsgaard
0 siblings, 1 reply; 10+ messages in thread
From: Arnout Vandecappelle @ 2013-12-10 16:54 UTC (permalink / raw)
To: buildroot
On 10/12/13 15:49, Thomas De Schampheleire wrote:
> On Tue, Dec 10, 2013 at 3:42 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:
>>
>> Hi,
>>
>> > The first seems to emphasize that we require a Linux kernel to be
>> > built in buildroot, while the second one leaves it in the middle. For
>> > packages that actually build kernel modules, like ktap, we really need
>> > the kernel inside buildroot, right? Are there any packages that depend
>> > on BR2_LINUX_KERNEL that do _not_ require an in-buildroot kernel?
>>
>> I don't think so, as BR2_LINUX_KERNEL is the symbol to build a linux
>> kernel internally.
>
> Ok, sounds logical.
> So what is the best comment text? Simply:
> "foo needs a Linux kernel to be built"
Sounds good to me. "to be built by buildroot" would be more accurate
but probably too verbose.
Regards,
Arnout
> ?
>
> If we can agree on something I will submit a patch to make this consistent.
>
> Thanks,
> thomas
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-12-10 20:50 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-10 11:59 [Buildroot] [PATCH v5 1/1] ktap: new package Anders Darander
2013-12-10 12:35 ` Peter Korsgaard
2013-12-10 12:55 ` Anders Darander
2013-12-10 13:01 ` Jeremy Rosen
2013-12-10 13:39 ` Peter Korsgaard
2013-12-10 14:36 ` Thomas De Schampheleire
2013-12-10 14:42 ` Peter Korsgaard
2013-12-10 14:49 ` Thomas De Schampheleire
2013-12-10 16:54 ` Arnout Vandecappelle
2013-12-10 20:50 ` Peter Korsgaard
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.