There are many options to debug code with the Linux kernel. Often, developers find themselves using printk and iterating building/test cycles to print messages and dig down - but other tools are available.
JTAG debuggers provide a way to explore the whole context of a processor by halting the system and inspecting memory and CPU registers.
Running a kernel in a virtual environment (QEmu/Virtme) provides a similar experience by enabling the whole virtual machine to be 'halted' and explored. To do this, we expose a debug TCP port, and connect GDB to the virtual environment, giving it the debug symbols of the Linux kernel which has been built.
This is a useful exercise to perform to help find ways to dig deeper in to the code - and understand some of the debug facilities available to you as well.
Extended debug features to read up on might include ftrace, or KGDB (kgdb is the 'internal' kernel debugger, but as you have a virtual environment, using GDB attached to the QEmu instance is likely more full-featured).
I believe you've already discovered strace (for debugging/tracing system calls) which is useful to determine what calls are being made into the kernel.
It might also be interesting (though not required) to investigate what ltrace does (the shared library version of strace) to see how the test applications (cam/qcam) interact with the libcamera library.
Feel free to discuss or record anything related here in this task.
There are many options to debug code with the Linux kernel. Often, developers find themselves using printk and iterating building/test cycles to print messages and dig down - but other tools are available.
JTAG debuggers provide a way to explore the whole context of a processor by halting the system and inspecting memory and CPU registers. Running a kernel in a virtual environment (QEmu/Virtme) provides a similar experience by enabling the whole virtual machine to be 'halted' and explored. To do this, we expose a debug TCP port, and connect GDB to the virtual environment, giving it the debug symbols of the Linux kernel which has been built. This is a useful exercise to perform to help find ways to dig deeper in to the code - and understand some of the debug facilities available to you as well.
Some useful reading may be found at : https://www.kernel.org/doc/html/v5.6/dev-tools/index.html In particular, https://www.kernel.org/doc/html/v5.6/dev-tools/gdb-kernel-debugging.html and
Extended debug features to read up on might include ftrace, or KGDB (kgdb is the 'internal' kernel debugger, but as you have a virtual environment, using GDB attached to the QEmu instance is likely more full-featured).
I believe you've already discovered strace (for debugging/tracing system calls) which is useful to determine what calls are being made into the kernel.
It might also be interesting (though not required) to investigate what ltrace does (the shared library version of strace) to see how the test applications (cam/qcam) interact with the libcamera library.
Feel free to discuss or record anything related here in this task.