• Running the email proxy
• Configuring git send-email with kw send-patch
• Testing the setup with kw send-patch

Commands

cd ~/github/emailproxy-container
docker compose up --build -d # run the container
docker exec -it emailproxy-container-server-1 /bin/bash # attach to the container terminal
emailproxy --no-gui --external-auth --config-file /app/emailproxy.config # start the email proxy
kw send-patch --send --private --to='<EMAIL-ADDRESS-1>','<EMAIL-ADDRESS-2>' # send the patch, use --simulate to dry-run

Notes

For this tutorial, we started by installing docker and docker-compose following this guide.

After editing the config file in the emailproxy-container repository clone, we ran the container with the following command:

docker compose up --build -d

After this, we attached the terminal to the container with:

docker exec -it emailproxy-container-server-1 /bin/bash

And then started the email proxy with:

emailproxy --no-gui --external-auth --config-file /app/emailproxy.config

Finally, we sent the email after some configurations to kw send-patch:

kw send-patch --send --private --to='<EMAIL-ADDRESS-1>','<EMAIL-ADDRESS-2>'

In this final step, I had some trouble when authenticating my email address. In the end I had to disable ad and tracking blocker extensions to be able to get the http://localhost/... URL.

Reference

Sending patches by email with git

Sending patches with git and a USP email

• Character devices
• Major and Minor Numbers
• File operations
• Bringing device IDs and file operations together
• A character device driver example
• Testing the simple_char driver

Commands

cat /proc/devices
stat <file>
mknod <file_name> <type> <major_num> <minor_num>
dmesg -w

@host
aarch64-linux-gnu-gcc write_prog.c -o write_prog
scp write_prog root@<VM-IP-ADDRESS>:~/
@VM
root@localhost:~# ./write_prog simple_char_node

Notes

• Character devices
  • Abstraction provided by Linux to support read/write devices with relatively small data transfers (one or a few bytes size).
  • Abstracted as files in the file system and accessed through file access system calls.
  • Example of devices: serial ports, keyboards, mice, etc.
  • Example of character device files: /dev/ttyS0, dev/input/mouse0, /dev/kmsg, /dev/zero.
• Major and Minor Numbers
  • Files associated with character devices are special types of files.
  • Allow users to interface with devices from the user space.
  • Under the hood, device files are the device drivers that handle the system calls for them.
  • The association between device files and devices is made with a device ID that consists of two parts: a major and a minor number
  • The device ID (major/minor number) is used to choose which driver to run to support a particular device.
• File operations
  • Character device drivers may implement functions to handle file access system calls.
  • The syscalls implemented by a device driver are set into a struct file_operations object.
  • There are several different file operations a character driver can implement.
  • Basic system calls: open, close, read, write.
  • Handled by open, release, read, and write functions stored in struct file_operations objects.

Tutorial steps

The following steps were executed to test the simple_char driver. This could be considered a basic example of a workflow for adding a module to the kernel, building, and installing it.

• Create an example character device
• Enable the device: make -C "$IIO_TREE" menuconfig
• Build linux image: kw build --clean && kw build
• Install the module:

  mkdir "${VM_DIR}/arm64_rootfs"
  sudo guestmount --rw --add "${VM_DIR}/arm64_img.qcow2" --mount /dev/vda2 "${VM_DIR}/arm64_rootfs"
  sudo --preserve-env make -C "${IIO_TREE}" INSTALL_MOD_PATH="${VM_DIR}/arm64_rootfs" modules_install
  sudo guestunmount "${VM_DIR}/arm64_rootfs"
  

• Start the VM: sudo virsh start arm64
• Connect to the VM: ssh root@$(sudo virsh net-dhcp-leases default | grep -oE '\b([0-9]{1,3}\.){3}[0-9]{1,3}\b')
• Get information about the module: modinfo simple_char
• Load the module: modprobe simple_char
• See kernel logs: dmesg | tail

Initially the device wasn’t writing to the buffer, giving me the following error:

root@localhost:~# ./write_prog simple_char_node
Error: 9wrote -1 bytes to buffer

But this was caused by a misconfiguration with the device interface (simple_char_node). By deleting and recreating it with the correct major number (cat /proc/devices | grep simp) I was able to write and read using the device.

root@localhost:~# ./write_prog simple_char_node
wrote 256 bytes to buffer
root@localhost:~# ./read_prog simple_char_node 
Read buffer: A new message for simple_char.

Reference

Introduction to Linux kernel Character Device Drivers

• Creating a simple example module
• Creating Linux kernel configuration symbols
• Configuring the Linux kernel build with menuconfig
• Installing Linux kernel modules

Commands

make -C "$IIO_TREE" menuconfig # to enable a module in the menuconfig
cd "$IIO_TREE" && kw build --clean # clean artifacts from previous compilations
cd "$IIO_TREE" && kw build # build image and modules
modinfo <module_name> # see information about module of given name
lsmod # @VM list loaded modules
insmod <module_file.ko> # loads module at given location
rmmod <module_name> # unloads module of given name
modprobe <module_name> # loads module of given name and its dependencies 
modprobe -r <module_name> # unloads module of given name
depmod --quick # updates the module dependency list only if a module is added or removed
dmesg | tail # see last logs

Notes

Although the tutorial told us that the entries in the Kconfig were in alphabetical order, the order did not appear to be alphabetical.

When installing the Linux kernel modules with kw, I got an error saying that ${VM_MOUNT_POINT} wasn’t defined, to fix this I had to replace it with ${VM_DIR}/arm64_rootfs for the following command:

sudo guestunmount "$VM_MOUNT_POINT"

The rest of the tutorial was very clear. By the end, I had a working Linux kernel with the example modules.

Reference

Introduction to Linux kernel build configuration and modules

• kw to develop and build a custom Linux kernel.
• IIO Linux kernel tree.
• Linux kernel compilation.
• Booting the custom Linux kernel.

Commands

kw ssh # initiate an SSH connection to the default remote
cd "$IIO_TREE" # go to the IIO tree directory
kw build --menu # safely modify `.config` w/ a TUI
kw build # compile Linux kernel from source considering local configurations
kw deploy --modules # only install modules into the VM

Notes

In this class I’ve installed the kw tool to build and boot a custom Linux kernel. The IIO (Industrial I/O subsystem) Linux kernel tree was also cloned and built.

The resulting setup for this class was:

/home
├── lk_dev
│   ├── iio
│   ├── kw
│   ├── shared_arm64
│   └── vm
│       ├── arm64_boot
│       │   ├── initrd.img-6.1.0-43-arm64
│       │   └── vmlinuz-6.1.0-43-arm64
│       ├── arm64_img.qcow2
│       └── base_arm64_img.qcow2
└── pietro
    └── github
        └── open-source-development
            └── lk_dev
                └── activate.sh

📝 kw can update itself using the self-update command.

kw self-update # update with master branch
kw self-update --unstable # update with unstable branch.

⚠️ When a new VM is launched with virsh, update the IP addess in kw configuration.

sudo virsh net-dhcp-leases default
cd "$IIO_TREE"
kw remote --add arm64 root@<VM-IP-address> --set-default

The kw ssh --get '~/vm_mod_list' command didn’t work for me, so I had to use scp root@<VM-IP-address>:~/vm_mod_list .

Sometimes, sudo virsh shutdown arm64 doesn’t work. In these cases I have to force it with sudo virsh destroy arm64

Reference

Building and booting a custom Linux kernel for ARM using kw

• Create a virtual machine (VM) with extracted kernel and initrd
• QEMU to run VMs
• libvirt to manage VMs and to automate
• Configure SSH access from the host to the VM
• Fetch the list of modules loaded in the guest kernel

Commands

launch_vm_qemu # launch a VM with qemu with the extracted kernel and initrd
create_vm_virsh # create a virsh VM with the extracted kernel and initrd
sudo systemctl start libvirtd && systemctl status libvirtd # start libvirtd and check its status
sudo virsh net-start default && sudo virsh net-list # start default network and list networks
sudo virsh console arm64 # re-attach to the console of the running vm
sudo virsh list --all # list all created VMs
sudo virsh dominfo arm64 # Show detailed information about a vm
sudo virsh start --console arm64 # start a previously created vm
sudo virsh shutdown arm64 # shutdown a vm gracefully
sudo virsh destroy arm64 # force shutdown a vm
sudo virsh undefine arm64 # remove stopped vm

Notes

To keep my activate.sh script versioned, I structured my setup as follows:

/home
├── lk_dev
│   ├── shared_arm64
│   └── vm
│       ├── arm64_boot
│       │   ├── initrd.img-6.1.0-43-arm64
│       │   └── vmlinuz-6.1.0-43-arm64
│       ├── arm64_img.qcow2
│       └── base_arm64_img.qcow2
└── pietro
    └── github
        └── open-source-development
            └── lk_dev
                └── activate.sh

The VMs had to be stored under the home directory for virsh access. Note that when creating the /home/lk_dev directory and it’s groups, I had to restart the computer, logging out and back in wasn’t enough.

The Debian image from the guide wasn’t available anymore, so the version used was the daily version 20260225-2399.

⚠️ Remember to start libvirtd after restarting the computer.

sudo systemctl start libvirtd
systemctl status libvirtd

The Debian image used doesn’t come with SSH installed, so I had to install it manually by running the VM with virsh and then executing:

sudo apt install update
sudo apt install openssh-server

After the setup was completed, I could access the VM successfully with SSH:

ssh root@192.168.122.135

Reference

Setting up a test environment for Linux Kernel Dev using QEMU and libvirt