Outreachy – 0x02

This is an interesting story. We all need to start from somewhere. It doesn’t matter how long or short our experience is or how far it goes or shallow the waters we have dived are, it’s always new space to learn.

This is one of the most important learning points that everybody should have as part of their life story. Here is my story. Re-visiting the basics and creating a hello world app but this time not as a toy printf() program, C/C++. No nothing like that. A real kernel C program that greets the world with happiness, exciting and new baby life!

I am very proud of my baby and I want to present it to you. It may seem silly to the more experienced of you but actually it’s a very important stone for everyone who wants to go deeper into kernel programming and it’s teaching one or two (or many more if you have the perspective lessons).

Without further ado here it is!

/* hello.c - simplest of all the kernel modules */

#include <linux/module.h> /* every module needs that */
#include <linux/kernel.h> /* printk KERN_INFO needs this */

int init_module(void) {
printk(KERN_INFO "Happy kernel days!\n");
/* non 0: init_module failed; module can't be loaded */
return 0;
}

void cleanup_module(void) {
printk(KERN_INFO "Sad Kernel Days\n");
}

Kernel modules must have at least two functions: a “start” (initialization) function called init_module() which is called when the module is insmoded into the kernel, and an “end” (cleanup) function called cleanup_module() which is called just before it is rmmoded.

To compile this you will need a Makefile similar to the following:

obj-m += hello.o 

all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

That’s the minimal Makefile ready to compile your module. After that you only need to run make and behold! Here’s your first amazing module.

The $(shell uname -r) is a useful call to return the current kernel build version — this ensures a degree of portability for the Makefile. The -C option switches the directory to the kernel directory before performing any make tasks. The M=$(PWD) variable assignment tells the make command where the actual project files exist. The modules target is the default target for external kernel modules. An alternative target is modules_install which would install the module (the make command would have to be executed with superuser permissions and the module installation path is required).

This should generate a .ko file. To load it into the kernel you run insmod hello.ko When you want to remove this module just run rmmod hello.ko

That was it right? Pretty easy and sweet you would say but this can teach you many lessons that you will find useful in the future (currently it helps me understand how to approach functions inside the Hypervisor Kernel Driver, understand the compilation, load and use printk to debug a kernel driver!)

Good luck and ping me if I can help some how 🙂

Advertisements

Virgin Week

Week 1

This is the first week of my Outreachy project and I am super excited! Being part of a team that is developing drivers for the Linux Kernel and specifically for the Hypervisor from Microsoft!

Sounds like an amazing experience and times to come, doesn’t it?

I am very grateful to everybody who helped me during my application phase, both from the Outreachy but also people from the kernel community who were always there with comments, suggestions and corrections.

Sometimes is difficult in the beginning to be in an environment where there’s a huge effort to keep the code consistent, clean and with an extremely high quality on the mind. But that’s more than rewarding!

I can say that in a month of preparing for the Linux Kernel, I got more than in a semester at the University in the past!

I am really looking forward to working with my mentor, revisit my C skills and learn more about Driver Development.

He already suggested me to go through the book ‘The Linux Kernel Programming’ by D. Love, which is what I am doing this week.

I am also looking at the specific display driver we are going to modify and add functionality, to understand its function as well as the data that is passed through various functions.

Happy times! Excited to be here and thanks again, everyone 🙂

Timeline

Get familiar with the functions in hyperv_fb driver in the kernel and especially functions like vfb_cfb_fillrect().

The data format passed into the functions is to be understood and studied as well as aiming for the final idea which is to record a dirty rectangle (that is the changed screen area) and update the screen accordingly.

Tests in different scenarios would need to be included with a variety of Linux distros like Redhat, Ubuntu, SLES. Different screen modes and Hypervisor types need to be listed, identified and tested as well.

Links

Here are some links that can be useful in the future but there is also a very good reference for everyone who goes through my blog: