commits November 2019

commits@lists.open-mesh.org

1 participants
108 discussions

[doc] backup-redmine/2019-11-07, master: doc: open-mesh/Kernel_debugging_with_qemu's_GDB_server (06d59ba)
by postmaster＠open-mesh.org 16 Nov '19

16 Nov '19

1 0

[doc] backup-redmine/2019-11-07, master: doc: open-mesh/OpenWrt_in_QEMU: allow memory hotplugging (60fdefe)
by postmaster＠open-mesh.org 16 Nov '19

16 Nov '19

1 0

[doc] backup-redmine/2019-11-07, master: doc: open-mesh/Kernel_debugging_with_qemu's_GDB_server (8c49436)
by postmaster＠open-mesh.org 16 Nov '19

16 Nov '19

1 0

[doc] backup-redmine/2019-11-07, master: doc: open-mesh/bridge-netfilter-loss.png (c1ce005)
by postmaster＠open-mesh.org 16 Nov '19

16 Nov '19

1 0

[doc] backup-redmine/2019-11-07, master: doc: open-mesh/emulation_overview.png (dd9ce47)
by postmaster＠open-mesh.org 16 Nov '19

16 Nov '19

1 0

[doc] backup-redmine/2019-11-07, master: doc: open-mesh/Advanced_Bridge_virtual_network (7080bc9)
by postmaster＠open-mesh.org 16 Nov '19

16 Nov '19

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2019-11-07,master >--------------------------------------------------------------- commit 7080bc933d1d365e290363b84e5dce65b3327d9c Author: Sven Eckelmann <sven(a)narfation.org> Date: Sun Oct 27 18:58:47 2019 +0000 doc: open-mesh/Advanced_Bridge_virtual_network >--------------------------------------------------------------- 7080bc933d1d365e290363b84e5dce65b3327d9c open-mesh/Advanced_Bridge_virtual_network.textile | 28 +++++++++++------------ 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/open-mesh/Advanced_Bridge_virtual_network.textile b/open-mesh/Advanced_Bridge_virtual_network.textile index e80626a..c28017e 100644 --- a/open-mesh/Advanced_Bridge_virtual_network.textile +++ b/open-mesh/Advanced_Bridge_virtual_network.textile @@ -1,8 +1,8 @@ -h1. Bridge interconnect +h1. Advanced Bridge virtual network {{toc}} -The simple interconnect from [[open-mesh:OpenWrt in QEMU#interconnect-initialization]] is a Linux bridge which allows full communication between the tap interfaces of all virtual instances. This is not optimal because fully connected meshes are not really interesting. But it is possible to use the bridge and netfilter functionality of the host's kernel to improve the bridge interconnect. +The simple virtual network from [[open-mesh:OpenWrt in QEMU#virtual-network-initialization]] is a Linux bridge which allows full communication between the tap interfaces of all virtual instances. This is not optimal because fully connected meshes are not really interesting. But it is possible to use the bridge and netfilter functionality of the host's kernel to improve the bridge virtual network. The tool of choice at the moment is is nft(ables). The following examples will introduce some common concepts based on nft. For older systems, ebtables and/or tc can also be used to achieve the same. @@ -23,7 +23,7 @@ h2. Preventing communication between nodes By default, all ports of a bridge can talk to each other. It is possible to prevent this forwarding behavior between the tap interfaces. The communication of the host with the virtual instances is not affected because it would be handled as output/input traffic. <pre><code class="shell"> -cat > interconnect-filter-traffic.nft << "EOF" +cat > virtual-network-filter-traffic.nft << "EOF" #!/usr/sbin/nft -f flush ruleset bridge @@ -36,9 +36,9 @@ table bridge filter { } EOF -chmod +x interconnect-filter-traffic.nft +chmod +x virtual-network-filter-traffic.nft -sudo ./interconnect-filter-traffic.nft +sudo ./virtual-network-filter-traffic.nft </code></pre> h2. Allow communication between specific nodes @@ -50,7 +50,7 @@ The previous example was not that useful for a mesh because nothing really meshe A simple chain is build here by allowing forwarding from one slave interface to another slave interface: <pre><code class="shell"> -cat > interconnect-filter-traffic.nft << "EOF" +cat > virtual-network-filter-traffic.nft << "EOF" #!/usr/sbin/nft -f flush ruleset bridge @@ -70,9 +70,9 @@ table bridge filter { } EOF -chmod +x interconnect-filter-traffic.nft +chmod +x virtual-network-filter-traffic.nft -sudo ./interconnect-filter-traffic.nft +sudo ./virtual-network-filter-traffic.nft </code></pre> h2. Loss between nodes @@ -84,7 +84,7 @@ The chain setup is already a nice test for mesh setups. But other characteristic A simple (uniformly distributed, bidirectional) packet loss can be implemented using <pre><code class="shell"> -cat > interconnect-filter-traffic.nft << "EOF" +cat > virtual-network-filter-traffic.nft << "EOF" #!/usr/sbin/nft -f flush ruleset bridge @@ -107,9 +107,9 @@ table bridge filter { } EOF -chmod +x interconnect-filter-traffic.nft +chmod +x virtual-network-filter-traffic.nft -sudo ./interconnect-filter-traffic.nft +sudo ./virtual-network-filter-traffic.nft </code></pre> h2. Throughput limit between nodes @@ -119,7 +119,7 @@ It is also possible to limit the maximum throughput per second for a link. The l !bridge-netfilter-throughput.png! <pre><code class="shell"> -cat > interconnect-filter-traffic.nft << "EOF" +cat > virtual-network-filter-traffic.nft << "EOF" #!/usr/sbin/nft -f flush ruleset bridge @@ -142,7 +142,7 @@ table bridge filter { } EOF -chmod +x interconnect-filter-traffic.nft +chmod +x virtual-network-filter-traffic.nft -sudo ./interconnect-filter-traffic.nft +sudo ./virtual-network-filter-traffic.nft </code></pre> \ No newline at end of file

1 0

[doc] backup-redmine/2019-11-07, master: doc: open-mesh/Advanced_Bridge_virtual_network (f23a179)
by postmaster＠open-mesh.org 16 Nov '19

16 Nov '19

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2019-11-07,master >--------------------------------------------------------------- commit f23a179bd6a6bdda9e200bc85c68fd7626d91417 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sun Oct 27 17:11:36 2019 +0000 doc: open-mesh/Advanced_Bridge_virtual_network >--------------------------------------------------------------- f23a179bd6a6bdda9e200bc85c68fd7626d91417 open-mesh/Advanced_Bridge_virtual_network.textile | 148 ++++++++++++++++++++++ 1 file changed, 148 insertions(+) diff --git a/open-mesh/Advanced_Bridge_virtual_network.textile b/open-mesh/Advanced_Bridge_virtual_network.textile new file mode 100644 index 0000000..bfbf9b4 --- /dev/null +++ b/open-mesh/Advanced_Bridge_virtual_network.textile @@ -0,0 +1,148 @@ +h1. Bridge interconnect + +{{toc}} + +The simple interconnect from [[open-mesh:OpenWrt in QEMU#interconnect-initialization]] is a simple bridge which allows full communication between all devices. This is not optimal to create not fully meshed setups. But it is possible to use the bridge and netfilter functionality of the host's kernel to improve the bridge interconnect. + +The tool of choice today is nft(ables). The following examples will introduce some common concepts based on nft. For older systems, ebtables and/or tc can also be used. + +It is important to understand the different filter hooks we have to use: + +* input +** from a bridge slave interface (here <code>tap*</code>) to the host bridge port +* output +** from the host bridge port to a bridge slave interface (here <code>tap*</code>) +* forward +** traffic between bridge slave interfaces (here <code>tap*</code>) + +!bridge-netfilter.png! + + +h2. Preventing communication between nodes + +By default, all ports of a bridge can talk to each other. It is possible to prevent this forwarding behavior between the tap interfaces. The communication of the host with the virtual instances is not affected because it would be handled as output/input traffic. + +<pre><code class="shell"> +cat > interconnect-filter-traffic.nft << "EOF" +#!/usr/sbin/nft -f + +flush ruleset bridge + +table bridge filter { + chain FORWARD { + type filter hook forward priority -200; policy accept; + meta obrname "br-qemu" drop + } +} +EOF + +chmod +x interconnect-filter-traffic.nft + +sudo ./interconnect-filter-traffic.nft +</code></pre> + +h2. Allow communication between specific nodes + +The previous example was not that useful for a mesh because nothing really meshes anymore. It could be more interesting to allow communication between specific nodes. + +!bridge-netfilter-chain.png! + +A simple chain is build here by allowing forwarding from one slave interface to another slave interface: + +<pre><code class="shell"> +cat > interconnect-filter-traffic.nft << "EOF" +#!/usr/sbin/nft -f + +flush ruleset bridge + +table bridge filter { + chain FORWARD { + type filter hook forward priority -200; policy accept; + + iifname "tap1" oifname "tap2" accept + iifname "tap2" oifname "tap1" accept + + iifname "tap2" oifname "tap3" accept + iifname "tap3" oifname "tap2" accept + + meta obrname "br-qemu" drop + } +} +EOF + +chmod +x interconnect-filter-traffic.nft + +sudo ./interconnect-filter-traffic.nft +</code></pre> + +h2. Allow communication between specific nodes with loss + +The chain setup is already a nice test for mesh setups. But other characteristics of a link might be interesting for a mesh protocol. A probability of packet loss is one of such a link characteristics. + +!bridge-netfilter-chain-loss.png! + +A simple (uniformly distributed, bidirectional) packet loss can be implemented using + +<pre><code class="shell"> +cat > interconnect-filter-traffic.nft << "EOF" +#!/usr/sbin/nft -f + +flush ruleset bridge + +table bridge filter { + chain FORWARD { + type filter hook forward priority -200; policy accept; + + iifname "tap1" oifname "tap2" numgen random mod 100 < 90 accept + iifname "tap2" oifname "tap1" numgen random mod 100 < 90 accept + + iifname "tap2" oifname "tap3" numgen random mod 100 < 90 accept + iifname "tap3" oifname "tap2" numgen random mod 100 < 90 accept + + iifname "tap1" oifname "tap3" numgen random mod 100 < 60 accept + iifname "tap3" oifname "tap1" numgen random mod 100 < 60 accept + + meta obrname "br-qemu" drop + } +} +EOF + +chmod +x interconnect-filter-traffic.nft + +sudo ./interconnect-filter-traffic.nft +</code></pre> + +h2. Allow communication between specific nodes with loss and throughput limit + +It is also possible to limit the maximum throughput per second for a link. + +!bridge-netfilter-loss-throughput.png! + +<pre><code class="shell"> +cat > interconnect-filter-traffic.nft << "EOF" +#!/usr/sbin/nft -f + +flush ruleset bridge + +table bridge filter { + chain FORWARD { + type filter hook forward priority -200; policy accept; + + iifname "tap1" oifname "tap2" numgen random mod 100 < 90 limit rate 10 mbytes/second accept + iifname "tap2" oifname "tap1" numgen random mod 100 < 90 limit rate 10 mbytes/second accept + + iifname "tap2" oifname "tap3" numgen random mod 100 < 90 limit rate 5 mbytes/second accept + iifname "tap3" oifname "tap2" numgen random mod 100 < 90 limit rate 5 mbytes/second accept + + iifname "tap1" oifname "tap3" numgen random mod 100 < 60 limit rate 1 mbytes/second accept + iifname "tap3" oifname "tap1" numgen random mod 100 < 60 limit rate 1 mbytes/second accept + + meta obrname "br-qemu" drop + } +} +EOF + +chmod +x interconnect-filter-traffic.nft + +sudo ./interconnect-filter-traffic.nft +</code></pre> \ No newline at end of file

1 0

[doc] backup-redmine/2019-11-07, master: doc: open-mesh/Vde_switch_virtual_network (fb6f153)
by postmaster＠open-mesh.org 16 Nov '19

16 Nov '19

1 0

[doc] backup-redmine/2019-11-07, master: doc: open-mesh/Kernel_debugging_with_qemu's_GDB_server (415845c)
by postmaster＠open-mesh.org 16 Nov '19

16 Nov '19

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2019-11-07,master >--------------------------------------------------------------- commit 415845cc9ebde8d5ace5dcf2dabc06ad1b01d733 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sun Oct 27 11:18:44 2019 +0000 doc: open-mesh/Kernel_debugging_with_qemu's_GDB_server >--------------------------------------------------------------- 415845cc9ebde8d5ace5dcf2dabc06ad1b01d733 ...Kernel_debugging_with_qemu's_GDB_server.textile | 48 ++++++++++++++++++++++ open-mesh/Kernel_hacking_Debian_image.textile | 43 ------------------- 2 files changed, 48 insertions(+), 43 deletions(-) diff --git a/open-mesh/Kernel_debugging_with_qemu's_GDB_server.textile b/open-mesh/Kernel_debugging_with_qemu's_GDB_server.textile new file mode 100644 index 0000000..d63421e --- /dev/null +++ b/open-mesh/Kernel_debugging_with_qemu's_GDB_server.textile @@ -0,0 +1,48 @@ +h1. Kernel debugging with qemu's GDB server + +h2. General + +The instances from [[OpenWrt in QEMU]] are listening on 127.0.0.1 TCP port <code>23000 + instance_no</code>. We will use in the following example instance number 1. Also the [[Kernel hacking Debian image]] is used as image. The gdb debugger can be started from the linux source directory and all <code>lx-*</code> helpers will automatically be loaded. + +h2. Debugging Session + +The debugging session with gdb can be started from the linux-next directory: + +<pre> +$ gdb -iex "set auto-load safe-path scripts/gdb/" -ex 'target remote 127.0.0.1:23001' -ex c ./vmlinux +</pre> + +The module can now be loaded in the qemu instance. After that, we have to reload the symbol information via <code>lx-symbol</code> and can set any kind of breakpoints on the batman-adv module: + +<pre> +^C +Thread 1 received signal SIGINT, Interrupt. +default_idle () at arch/x86/kernel/process.c:581 +581 trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id()); +(gdb) lx-symbols /home/sven/tmp/qemu-batman/batman-adv/net/batman-adv/ +loading vmlinux +scanning for modules in /home/sven/tmp/qemu-batman/batman-adv/net/batman-adv/ +scanning for modules in /home/sven/tmp/qemu-batman/linux-next +loading @0xffffffffa0000000: /home/sven/tmp/qemu-batman/batman-adv/net/batman-adv//batman-adv.ko +(gdb) b batadv_iv_send_outstanding_bat_ogm_packet +Breakpoint 1 at 0xffffffffa0005d60: file /home/sven/tmp/qemu-batman/batman-adv/net/batman-adv/bat_iv_ogm.c, line 1692. +(gdb) c +</pre> + +h2. Python datastructure helper + +It is also possible to evaluate data structures in the gdb commandline using small python code blocks. To get for example the name of all devices which batman-adv knows about and the name of the batman-adv interface they belong to: + +<pre> +python +import linux.lists +from linux.utils import CachedType + +struct_batadv_hard_iface = CachedType('struct batadv_hard_iface').get_type().pointer() + +for node in linux.lists.list_for_each_entry(gdb.parse_and_eval("batadv_hardif_list"), struct_batadv_hard_iface, 'list'): + hardif = node['net_dev']['name'].string() + softif = node['soft_iface']['name'].string() if node['soft_iface'] else "none" + gdb.write("hardif {} belongs to {}\n".format(hardif, softif)) +end +</pre> \ No newline at end of file diff --git a/open-mesh/Kernel_hacking_Debian_image.textile b/open-mesh/Kernel_hacking_Debian_image.textile index 69d4af0..1e6cd15 100644 --- a/open-mesh/Kernel_hacking_Debian_image.textile +++ b/open-mesh/Kernel_hacking_Debian_image.textile @@ -403,46 +403,3 @@ mkfifo remote-dump ssh root(a)192.168.251.51 'tcpdump -i enp3s0 -s 0 -U -n -w - "port not 22"' > remote-dump wireshark -k -i remote-dump </pre> \ No newline at end of file - -h2. Using GDB - -The instances are listening on 127.0.0.1 TCP port <code>23000 + instance_no</code>. We will use in the following example instance 1. The gdb debugger can be started from the linux source directory and all <code>lx-*</code> helpers will automatically be loaded. - -The debugging session with gdb can be started from the linux-next directory: - -<pre> -$ gdb -iex "set auto-load safe-path scripts/gdb/" -ex 'target remote 127.0.0.1:23001' -ex c ./vmlinux -</pre> - -The module can now be loaded in the qemu instance. After that, we have to reload the symbol information via <code>lx-symbol</code> and can set any kind of breakpoints on the batman-adv module: - -<pre> -^C -Thread 1 received signal SIGINT, Interrupt. -default_idle () at arch/x86/kernel/process.c:581 -581 trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id()); -(gdb) lx-symbols /home/sven/tmp/qemu-batman/batman-adv/net/batman-adv/ -loading vmlinux -scanning for modules in /home/sven/tmp/qemu-batman/batman-adv/net/batman-adv/ -scanning for modules in /home/sven/tmp/qemu-batman/linux-next -loading @0xffffffffa0000000: /home/sven/tmp/qemu-batman/batman-adv/net/batman-adv//batman-adv.ko -(gdb) b batadv_iv_send_outstanding_bat_ogm_packet -Breakpoint 1 at 0xffffffffa0005d60: file /home/sven/tmp/qemu-batman/batman-adv/net/batman-adv/bat_iv_ogm.c, line 1692. -(gdb) c -</pre> - -It is also possible to evaluate data structures in the gdb commandline using small python code blocks. To get for example the name of all devices which batman-adv knows about and the name of the batman-adv interface they belong to: - -<pre> -python -import linux.lists -from linux.utils import CachedType - -struct_batadv_hard_iface = CachedType('struct batadv_hard_iface').get_type().pointer() - -for node in linux.lists.list_for_each_entry(gdb.parse_and_eval("batadv_hardif_list"), struct_batadv_hard_iface, 'list'): - hardif = node['net_dev']['name'].string() - softif = node['soft_iface']['name'].string() if node['soft_iface'] else "none" - gdb.write("hardif {} belongs to {}\n".format(hardif, softif)) -end -</pre> \ No newline at end of file

1 0

[doc] backup-redmine/2019-11-07, master: doc: open-mesh/Kernel_hacking_Debian_image (71c3e48)
by postmaster＠open-mesh.org 16 Nov '19

16 Nov '19

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2019-11-07,master >--------------------------------------------------------------- commit 71c3e48673e076b9844a37ef8edf4aa0fccbd3a9 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sun Oct 27 13:48:57 2019 +0000 doc: open-mesh/Kernel_hacking_Debian_image >--------------------------------------------------------------- 71c3e48673e076b9844a37ef8edf4aa0fccbd3a9 open-mesh/Kernel_hacking_Debian_image.textile | 120 +++++++------------------- 1 file changed, 29 insertions(+), 91 deletions(-) diff --git a/open-mesh/Kernel_hacking_Debian_image.textile b/open-mesh/Kernel_hacking_Debian_image.textile index 20cd1e7..e1265fc 100644 --- a/open-mesh/Kernel_hacking_Debian_image.textile +++ b/open-mesh/Kernel_hacking_Debian_image.textile @@ -292,90 +292,47 @@ make olddefconfig make all -j$(nproc || echo 1) </code></pre> -h2. Start of the simple environment +h2. Building the batman-adv module -The two node environment must be started inside a screen session. The hub (bridge with 5 tap devices) has to be started first to have a simple network. A more complex network setup can be on the page [[vde switch interconnect]] and [[bridge interconnect]] +The kernel module can be build outside the virtual environment and shared over the 9p mount. The path to the kernel sources have to be provided to the make process -<pre> -cat > hub.sh << "EOF" -#! /bin/sh -USER="$(whoami)" -BRIDGE=br-qemu - -sudo ip link add "${BRIDGE}" type bridge -for i in `seq 1 5`; do - sudo ip tuntap add dev tap$i mode tap user "$USER" - sudo ip link set tap$i up - sudo ip link set tap$i master "${BRIDGE}" -done - -sudo ip link set "${BRIDGE}" up -sudo ip addr replace 192.168.251.1/24 dev br-qemu -EOF +<pre><code class="shell"> +make KERNELPATH="$(pwd)/../linux-next" +</code></pre> + +The kernel module can also be compiled for better readability for the calltraces: + +<pre><code class="shell"> +make EXTRA_CFLAGS="-fno-inline -Og -fno-optimize-sibling-calls" KERNELPATH="$(pwd)/../linux-next" V=1 +</code></pre> -chmod +x hub.sh -</pre> +h2. Start of the environment -The @SHARED_PATH@ in run.sh has to be changed to a valid path which is used to share the precompiled batman-adv.ko and other tools +h3. interconnect initialization -<pre> -cat > run.sh << "EOF" -#! /bin/bash +The [[open-mesh:OpenWrt_in_QEMU#interconnect-initialization|interconnect.sh from the OpenWrt environment]] can be reused again. -if [ -z "${STY}" ]; then - echo "must be started inside a screen session" >&2 - exit 1 -fi +h3. VM instances bringup -SHARED_PATH="$(pwd)" -NUM_SESSIONS=5 -BASE_IMG=debian.img +The [[open-mesh:OpenWrt_in_QEMU#VM-instances-bringup|run.sh from the OpenWrt environment]] can mostly be reused. There are only minimal adjustments required. -BOOTARGS=() -BOOTARGS+=("-kernel") -BOOTARGS+=("linux-next/arch/x86/boot/bzImage") -BOOTARGS+=("-append") -BOOTARGS+=("root=/dev/vda rw console=ttyS0 nokaslr") - -for i in $(seq 1 "${NUM_SESSIONS}"); do - if [ ! -e "/sys/class/net/tap${i}" ]; then - echo "hub script must be started first to create tap$i interface" >&2 - exit 1 - fi -done - -for i in $(seq 1 "${NUM_SESSIONS}"); do - normalized_id="$(echo "$i"|awk '{ printf "%02d\n",$1 }')" - twodigit_id="$(echo $i|awk '{ printf "%02X", $1 }')" - - qemu-img create -b "${BASE_IMG}" -f qcow2 root.cow$i - screen qemu-system-x86_64 -enable-kvm -name "instance${i}" \ - "${BOOTARGS[@]}" \ - -display none -no-user-config -nodefaults \ - -m 512 -device virtio-balloon \ - -cpu host -smp 2 -machine q35,accel=kvm,usb=off,dump-guest-core=off \ - -drive file=root.cow$i,if=virtio,cache=unsafe \ - -nic tap,ifname=tap$i,script=no,model=virtio-net-pci,mac=02:ba:de:af:fe:"${twodigit_id}" \ - -nic user,model=virtio-net-pci,mac=06:ba:de:af:fe:"${twodigit_id}" \ - -virtfs local,path="${SHARED_PATH}",security_model=none,mount_tag=host \ - -gdb tcp:127.0.0.1:$((23000+$i)) \ - -device virtio-rng-pci \ - -serial mon:stdio - sleep 1 -done -EOF +The BASE_IMG is of course no longer the same because a new image "debian.img" was created for our new environment. The image also doesn't contain a bootloader or kernel anymore. These must now be supplied manually to qemu. + +<pre><code class="shell"> +BASE_IMG=debian.img +BOOTARGS+=("-kernel" "linux-next/arch/x86/boot/bzImage") +BOOTARGS+=("-append" "root=/dev/vda rw console=ttyS0 nokaslr") +</code></pre> -chmod +x run.sh -</pre> +h3. Automatic test initialization -The test-init.sh script can be used to automatically initialize the testsetup during boot: +The [[open-mesh:OpenWrt_in_QEMU#Automatic-test-initialization|test-init.sh from the OpenWrt environment]] is always test specific. But its main functionality is still the same as before. A simple example would be: -<pre> +<pre><code class="shell"> cat > test-init.sh << "EOF" #! /bin/sh set -e -export PATH="/host/batctl/:$PATH" ## get internet access dhclient enp0s2 @@ -396,27 +353,8 @@ ip link set up dev bat0 EOF chmod +x test-init.sh -</pre> - - -Everything can then be started up inside a screen session - -<pre> -screen -./hub.sh -./run.sh -</pre> - -h2. Building the batman-adv module - -The kernel module can be build outside the virtual environment and shared over the 9p mount. The path to the kernel sources have to be provided to the make process - -<pre> -make KERNELPATH="$(pwd)/../linux-next" -</pre> +</code></pre> -The kernel module can also be compiled for better readability for the calltraces: +h2. Start -<pre> -make EXTRA_CFLAGS="-fno-inline -Og -fno-optimize-sibling-calls" KERNELPATH="$(pwd)/../linux-next" V=1 -</pre> \ No newline at end of file +The startup method [[open-mesh:OpenWrt_in_QEMU#Start|from the OpenWrt environment]] should be used here. \ No newline at end of file

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits November 2019