I run Gentoo, and I compile an out-of-tree network kernel module on the host OS where I have a full dev environment. I then copy those kernel modules over to the KVM'd guest OS's where I load and test them.
The problem is, I have to make a few minor changes to header files to the kernel sources each time I upgrade the kernel on both the host OS and the guest OS because I compile on the host OS and run on the guest OS. I also need to make sure the host and guest are running the same kernel version, however, there are minor differences in built in modules (I.e. the host OS is setup for virtualization, video, etc... whereas the guest OS's are slightly different to include serial consoles that output the ring buffer to the host OS). So mostly it's the same .config from the host and I copy this to the guest.
My biggest concern is that I'm wondering if that could possibly have an effect on the stability/testing of my KM's since I compile on one, and run on the other. I haven't had major problems doing this and I'm guessing the times when my stuff oops, I've found so far it's been my code.
I don't have a full dev environment within my guest OS's because I put alot of effort in customizing my desktop and the scripts/tools and such that I run on it. My guest OS's are minimal Gentoo installs that only have the tools I need to test and debug.
So that's how I do it and I'm wondering if more experienced devs have a better way of doing kernel develpment/testing and simpler ways of getting by the kernel upgrades.
Related
I am trying to read the LDD book by Jonathan Corbet, Greg Kroah-Hartman, Alessandro Rubini and implement the sample modules. So to begin with, I tried setting up a development system. Installed Ubuntu 16.04 Xenial. Now, I just created a directory and wrote the hello_world module with a Makefile. Got it built and run it, verified the dmesg logs.
Is that all the development setup? I searched online and found articles where they are asking to download and compile the kernel, use a VM to boot the kernel. What is the reason? Or what am I missing?
Is there any better article which clarifies this?
Thanks
hago
You can try one more way:
If you have native windows, install virtual machine software such as
Virtual box. Get your favourite Linux distribution (no bias, just
an example - Ubuntu) and install it through Virtual box.
Get the latest kernel (or of your choice) from kernel.org.
Choose the platform you want to build this kernel for. E.g arm64 or x86.
In case you do not have real boards (e.g RPi for arm variant), you can use qemu-arm64 or qemu-x86 to run your compiled kernel. This is also a good option when users do not have the boards.
Another good use case for using qemu for the newbie kernel developers is even they write some modules which crashes, then the qemu instance is crashed so no harm.
I think using qemu is a good option for people who starts to learn kernel programming and also want to try writing some of their modules and do not intend to purchase hardware at this point of time.
It depends on your target. For your case, you have made a kernel driver for your computer (it run Linux kernel).
But if you want to develop a Kernel driver for another target like Rasberry Pi, ARM board, X86-X64 board, ... you must learn to compile, edit Kernel config, boot Kernel image, ... because each target has different kernel versions.
You can refer to this training for more detail: https://bootlin.com/training/embedded-linux/
Is it possible to create a self contained binary distribution of a VM with VirtualBox or some other tool?
My requirements:
no VirtualBox install
self contained binary/-ies to start and stop VM (with all VirtualBox environment support on it)
possibly no administrator rights to start and stop the VM
at least windows, but better if cross platform
In theory it is possible to create a giant blob that bundles some kind of hypervisor which will first extract install along with the VM (disk, config. etc.) and then run itself and the extracted VM.
However, that is only theory. In practice, hypervisors are very complex pieces of software and require some sort of ring-0 access (kernel level) to talk directly with the CPU and other hardware and VirtualBox is no exception. So installing them, on any operating system that cares even a little bit about security, will require admin/root/supervisor access as you cannot install drivers and other kernel components otherwise.
If performance is of no concern, it may be possible to use an emulator like Qemu/Bochs which can work without ring-0 access. However, I'm not currently aware of any projects that have such self-extracting and runnable emulators for pre-baked VM images (even more so on Windows).
As Tekn0 writes, it is required a low level access to the host OS layer.
I found the project Portable VirtualBox which setups the host machine on the fly.
I tested it and it is not enough satisfactory. From the site:
Note
VirtualBox needs several kernel drivers installed and needs to start
several services: if the drivers and services are not already
installed you’ll need administrator rights to run Portable-VirtualBox.
When Portable-VirtualBox starts, it checks to see if the drivers are
installed. If they are not it will install them before running
VirtualBox and will remove them afterward. Similarly,
Portable-VirtualBox checks to see if the services are running. If not,
it will start them and then stop them when it exits.
The result is a product not always running and with strange kernel errors.
There is another project (starting from Tekn0 observations) Kquemu Portable
and finally Bochs.
I have a device driver that is freezing the OS. The mouse wont even move. I am trying to debug this issue and I believe one good approach is to use gdb with qemu, two things I have never used before. Is there a better approach?
So first I need to compile the kernel with debug symbols which I have done already.
Now, there is a new file that is generated called vmlinux that is located in that same folder as the source. It seems that I also need a bzImage file according to this so I can run the newly compiled kernel using:
qemu-system-i386 -kernel bzImage
or in debug mode
qemu-system-i386 -s -S -kernel bzImage
I cannot locate the bzImage file. Where do I find it or what is missing here? Is the bzImage referring to the OS Image I created using qemu-img create?
Also, what I do not understand is that now the kernel is compiled (vmlinux) how does I run it with qemu? So my question is when I run it with qemu or the debugger is the kernel running as an app in my main OS?
also how can I install my device driver? My understanding the kernel is not Ubuntu so there is no UI?
Also, I installed qemu and when I type qemu I get command not found. I am guessing I have to pick a specific processor emulator as in qemu-system-i386, qemu-system-x86_64, or qemu-x86_64?
How is qemu different or similar to the kvm command?
Thanks.
So, if I understand the problem correctly, you have a kernel module that needs no specific hardware. When you are working with the module, the system freezes but the kernel log contains nothing special.
The following may be helpful.
Getting the log
The symptoms you described may still be a result of a kernel oops or panic. The logging facilities sometimes die before they can output the information about the error to the log file. You may try to output the log via a serial port, this should be more reliable.
As your kernel module does not need any specific hardware, the easiest way is probably to install the same Linux distro as you use to a virtual machine and connect the virtual serial port (COM) of that machine to a pipe on your host system.
This is usually quite easy to do. For example, this blog post contains the detailed instructions in case the host OS and the guest OS are Ubuntu 11.10.
VirtualBox is used there to manage the virtual machines. If you prefer QEMU, this should be possible as well. I suppose it is a bit easier to go with VirtualBox though but it is a matter of personal preference.
Basically, you need to perform the following steps.
Create a virtual machine and install the Linux distro you need as a guest OS there.
Enable a serial port (COM1, ...) in the configuration of the virtual machine and configure it to connect to a special file on the host ("host pipe"), say /tmp/vbox_serial.
Start the guest OS and adjust its boot options: at least, add console=ttyS0,115200 or something like that to the kernel options in the boot loader menu.
On the host, start minicom, socat or whatever else to read from /tmp/vbox_serial.
That is it. Now you should get the kernel log of the guest OS pouring to your host system via /tmp/vbox_serial. If the guest system crashes then, you will get the log even if it is not saved into a file on the guest itself.
To make things easier, you may use socat on your host system rather than minicom that the author of that blog post suggests. The power of minicom is probably not needed here.
This way, you can use socat and tee to save the log to guest.log file while still outputting it to the console:
socat /tmp/vbox_serial - | tee guest.log
If there was a kernel oops or panic, the backtrace in the log usually helps to find out what
has gone wrong.
Detecting Deadlocks
If you have obtained the full log via a serial connection or some other means and still there is nothing suspicious there and you suspect there has been a deadlock in the kernel,
lockdep tool may help. It is included into the kernel (but you may need to rebuild the kernel with CONFIG_LOCKDEP_SUPPORT=y).
Lockdep detects the potential deadlocks and outputs the results to the kernel log. This presentation may help you analyse its output.
Tracing Facilities
If you need tracing of some events in the kernel to debug your system, there are some tools that could be handy.
Kprobes - a kind of breakpoints you can set in almost arbitrary place in the kernel. Can be used to trace function calls among other things, with a moderate performance impact.
SystemTap - a powerful system to analyze what is going on in the kernel. Part of it is based on Kprobes.
Ftrace - a tracing system included into the kernel, incurs less overhead than Kprobes if that matters.
I am studying Linux driver programming and in it, it is recommended that I work on self-compiled Linux kernels and not any distributions. I have tried compiling Linux 2.6.9 in ubuntu but the process returns errors in 'make menuconfig' stage.
I would prefer to work with Linux in a virtual environment so that I can fearlessly experiment with the kernel. So, is there any way I can compile and run Linux in a virtual machine (say VMware installed on Windows)? I can use live CDs for the purpose of compiling the kernel.
So in short, please suggest, how can I compile, install and run Linux kernel in a virtual machine in an error-free way?
I searched and read this. But after following these steps when I restarted my computer there was no separate Linux 3.2.17 OS. But my ubuntu 12.04 was now showing 3.2.17 kernel. Although this is the first time I could compile a whole kernel on ubuntu without any error, I want to load that kernel on other partition and use it as an independent OS. So, if anyone can tell, what to do in addition to the steps in the tutorial so that I can achieve this?
The simplest thing to do is probably to install some Linux distribution on a VM, such as VMWare or VirtualBox, and continue from there. You could try using a live-cd, but I'm guessing that the lack of persistent storage might get irritating. There are, of course, ways around that, but installing some distribution is probably simpler, and you don't really need that much disk space for it if all you want to do is compile a kernel.
If all you want to do is compile a kernel module, and if you already have some pre-installed Linux environment, you should also note that modern Linux installations allow you to compile modules without the need to re-compile the entire kernel. You will need the kernel source and headers, though. See, for example, this document.
And BTW, speaking of modern kernels, why did you choose to use 2.6.9? It's almost 8 years old by now. Newer kernels might actually be easier to develop for. Also, there's no guarantee that
modules developed with such an old kernel would still work with current ones.
I suggest you to read this page. This document shows you how to boot your personal kernel on qemu and how to use the debugger on it.
Kernelnewbies is the right place to start kernel hacking. This website contains a set of rich tutorials about kernel hacking and tweaking just for newbie Linux developers. Also, you can join the community and start contributing to some tiny Linux projects.
For a quick start, follow the instruction from the "kernel first patch" tutorial. Since you're cloning the "origin" remote repository in this tutorial, you'll work on the latest branches of Linux kernel. So, there's no need to worry about working on an old version of Linux. Meanwhile, if you're not comfortable working with git trees, you can always download the latest version of Linux from front page of "kernel.org".
I have a couple Freescale 68HCS08 MCUs connected in an I2C network, running different programs. When I click "debug," Codewarrior checks for a running instance of hiwave.exe to load and debug the program. I'd like to debug both simultaneously, which means having two instances running.
What is the best way to do this? Do I need two PC's? Is it better to try and manually reload the MCU's, using the Build command instead of Debug in Codewarrior?
I can run two instances of hiwave.exe manually, and then use the "File"->"Load Application" menu item to select the .abs file. It seems to run both instances fine, including code display and breakpoints, although I'm using full-chip simulation rather than a hardware debugger at the moment. I would guess that's where most of the fun is, in making sure that each instance uses the correct debugger, especially if you're using two of the same USB devices.
"That's too easy", I can hear you saying. Fine, take option 2:
I do all my CodeWarrior / Hiwave stuff in "Windows XP Mode", a Virtual PC running under Windows 7, mostly because CodeWarrior's installer doesn't run on 64-bit architectures (or it didn't a few months ago, for which I yelled at them in their forums).
I'm not entirely sure of the licensing technicalities (if you have Windows 7 pro, you should get at least one free license to use the Windows XP mode), but perhaps you could do something similar - e.g. run a Virtual PC environment with one of your debuggers passed through to the virtual system (Windows Virtual PC and other virtualization environments let you pass USB devices through), and have your other debugger still attached to the 'host' system. You could then have CodeWarrior/Hiwave installed on both the virtual and host systems, with one controlling system A and the other controlling system B. USB fun-time still applies, as you'd have to make sure the 'correct' USB debugger was passed through to the virtual system.
The debugger, HIWAVE.EXE will not work in either Windows XP mode, nor VMs such as VMWARE WORKSTATION, nor any of the VMs available in Linux. This is to do with the way the driver for the USB MULTILINK has been architecured.
Making Codewarrior v6.x work in Windows 7 is easy, by patching the installer.
We were not able to get the debugging pod to work to debug live hardware, because of the fact that the USB driver is implemented with Jungo Windriver, and, as per other articles, neither of the virtual machines can push that across into the virtual environment.
I have wasted months trying to solve this, in the end we resurrected old XP licenses and installed XP. However safe to say that, this, combined with Freescale's lack of vision to allow people running Linux to develop for the silicon, forced me into a decision that I will no longer use their products.
However, running multiple instances of the debugger is possible. The maximum seems to be around 20