Flock 2014: An overview

Sadly, Flock 2014 is over. I have to say it was one of the best conferences I’ve ever been to so far both in terms of organization and the people.

I travelled to Flock from Brno with three fellow Red Hatters, Jiri Folta, Igor Klimes and Cole Robinson, who came from the US and is on my team. It was great to meet him in person! Throughout the week we had many interesting conversations about various stuff.

Since this was my first Flock, I didn’t really know what to expect. I expected the two events to be a big hit, and they were! On the first day we went to a local pub where you could tap your own beer! Luckily for me, our teambuilding in Brno was in a pub like that and I knew how to use the tap machine. (You have type in your number and remember that ;)) The best thing in this pub was that you had a leaderboard where pubs ranked in terms of liters of beer drank. Needless to say, Flock 2014 outdrank the whole Czech Republic.

On the first day was my talk titled “How is the Fedora Kernel different?”, I don’t really think that it was any good to be honest, but people did tell me that it was good, so I don’t know what to think… :-)

Second day was another great day! My favourite talk this day was “Fedora Server Role-ing Along” by Stephen Gallagher. It explained how the roles fit into the model and how Cockpit is the crown of this all. I guess it will be time to give Fedora Server a try!This day’s night was spent on a boat! It was pretty cool, we went around the river and saw a lot of ‘tourist stuff’. I managed to talk with a lot of interesting people on the boat.

On the third day, I watched a few talks but in the afternoon we (the Hungarian fedora community) went on a sightseeing trip into deep Prague. Prague is an amazing city, I must say! After we went back to the hotel I talked with Cole if he wanted to go for a dinner. We grabbed a few Fedorians and went to an Lebanese restaurant. It was fun to meet new people! The greatest part of this day was going to a local club where they had three floors each with a different type of music. I almost forgot to mention that Luke and Cole had been talking about DnB for 2 hours straight, before, during and after the dinner. This was probably the best night we had!

The last day, I was really tired so I just went for a few talks and then the tiredness from last night killed me, so we decided to go home. I really wanted to watch my teammate’s talk about Virtualization, but I was so tired that I almost fell asleep at the previous talk, even though it was a great talk!

So, it seems Flock is a celebration of one of our foundations. Friends. Amazing. I hope to see more of the amazing people Fedora has next year in North America!

Thanks for reading,
Levente Kurusa
Fedora Project Hungary

How to create a custom PCI device in QEMU

Let’s hack QEMU. That is what I was saying a few days ago. I always wanted to explore QEMU and the whole virtualization stack, but never got around to it, and now that I had the time to do so I gave it a try.

It was pretty rough. I wasn’t able to find any good tutorials on how to add custom virtualized devices to QEMU, not even ISA or PCI, so I decided that I’ll be writing up a blog post about the creation of a very simple PCI device in QEMU. Here is a list of what we will cover during this post series:

  • A PCI device in QEMU, from which you can read byte-by-byte a string (e.g. “Hello, world!”)
  • A Linux kernel module to read it and possibly write to it!

… and  a list of what we will not cover:

  • Getting the source code of Linux and QEMU
  • Configuring and building them

Let us start. We will create a new file called pci-tutorial.c in the QEMU sources in folder hw/char/ since we are creating a character device. Here is a gist showing what you should put inside the file: pci-tutorial.c

I know that is a bit too much for a single shot, so let me tell you how it all works. We’ll use a technique I call ‘reverse-read’ for understanding the code. So, looking at the bottom of the code you can see a macro called
'type_init' with the sole parameter being the init function of the file. This is called 'type_init' since QEMU creates an object orientated interface, and we need to register a type. The macro invokes 'pci_tut_register_types' which will register the type which is defined by the struct 'pci_tut_info'. Here we have a field called name and that is what defines the name we will pass to QEMU's '-device' flag.

Function ‘pci_tutdev_class_init’ is what you can call the class static initializer. This is the function which sets up the static variables of the class. Since we specified we are creating a PCI subclass in the struct ‘pci_tut_info’, we are being passed a PCIDeviceClass in which we can specify PCI-specific information (e.g. vendor, device IDs). Note, we are also specifying an init function called ‘pci_tutdev_init’ which can be thought of like it was the constructor for the pci-tutdev objects! Likewise there exists an uninit function which can be the destructor if you’d like.

If this was a bit rough here is an image showing the flow:

Now, we need to add this file to the Makefile.objs in order for the QEMU build system to build this and link it to the resulting executable as well:

Add the following line:
obj-$(CONFIG_PCI) += pci-tutorial.o

What this says is pretty simple, if the configuration option called CONFIG_PCI is enabled then the pci-tutorial.c file will be built and linked into the QEMU emulator.

Now, if you build QEMU and pass ‘-device pci-tutdev’ to it you will most likely see something like this provided you start a Linux kernel inside it:


Now, there is nothing fun in that until you write a simple module for the Linux Kernel to pick it up. In the next part of this series we’ll cover how you can write a simple Linux kernel module that will pick up this device.

Thanks for reading!

Levente Kurusa
Fedora Project Hungary

Report of Developer Conference 2014 in Brno, CZ

The Team

  • Gergely Rákosi (RGeri77) - Driver / Spontaneous lightning talker
  • Péter Czanik (CzP) - Attendee / Industrial tactic thief
  • Szilveszer Liszy (cryorat) - Attendee / Free food(+accommodation) user/abuser
  • Levente Kurusa (Levex) - speaker / linux kernel preacher

Day one

We didn’t really arrive by Friday due to some travel difficulties
we had before the event. One of the greatest things I missed during
the conference was that we missed the guided city tour. The friends
I made there told me it was awesome and it’s a real pity we missed it.

Day two

This is the day we started our trip to Brno. Everything went smooth
except that our driver, RGeri77, was a little bit, oh well an hour late.
I woke up at around 3am and met with cryorat by 4am. Once we arrived
in Budapest, RGeri77 picked us up at around 7am. (Yup, we arrived there
by 6am.) After RGeri77 (finally) picked us up we began the trip to Brno.

Once we had arrived in Brno, we immediately went to our hotel to check
in. After that we went directly to the IT faculty of the Masernyk
University where we started to watch some lectures. Since we arrived
in Brno by 11am, we missed quite a few good talks. One talk I especially
wanted to listen to and missed was the “What’s up in kernel land” one.

I went to quite a few talks there, all of them was very interesting and
I think I made some new friends there and broadened my mind in some
particular areas that were covered during this extraordinary event.

In the afternoon, we got some swag (as usual! :)), got food, in which
cryorat was very interested. After an other round of talks, we went
back to the hotel at around 6pm, and got ready for the Red Hat
sponsored party in a local pub/club called Fléda. I left at around
10pm due to tiredness from the early wake up.

Day three

The day of my talk! I was very excited to see how would my talk go. The
schedule site had about 35 attendees registered, but in the end there
were like 50 people listening to my talk. The title of my talk was:
Introduction to Linux Kernel Development, one thing I found very bad
is that there was no HDMI available, so I couldn’t present from my
ultrabook since this one has no VGA outputs. Sucks, since I wanted
to ‘demo’ the creation and the sending of a patch to upstream Linux
Kernel. This resulted in me elaborating waaay more on the topics
in my presentation so that I wouldn’t finish way before the time’s up.


It was excellent conference. I had huge fun there and I hope that I made
some contacts and friendships. I want to say thanks to Jiri Eischmann and
Radek Vokal for organizing this awesome event and giving me an
opportunity to talk. I’ll most likely come next year as well.

In other news…

The Kernel series I was posting will be continuing soon.

Setting up your environment for kernel development

In my previous post I talked about the fears some software engineers have when they are either required to do kernel development or when they just want to try it. Mostly the first, because when somebody wants to do this because of their curiosity then they will most likely understand the ‘risks’ involved.

So, what are the requirements for beginning kernel development? Most importantly the C language. Yup, a language that every programmer knows about. Some even fear it, but that is not the scope of my writing. You will also need deep understanding of pointers, you are not afraid of seeing the following: *(uint32_t *)0xb8000 = 0x1337 . Yes, I know that’s pretty basic, I didn’t manage to come up with anything that looks more weirdish. Last, but not least you also need to understand (quickly) bitwise stuff. Something like this: b[i / 8] &= ~(1 « (i & 7)); Try to guess what it does.

Still here? Alright, so you might have been wondering how to actually do work. Well, the first step would be to grab the packages you will need for building the kernel. Execute the following to quickly get them.

sudo yum install -y make git git-email gcc

This command will have installed all the stuff you need to get the source code of the kernel and build it. Now, the next step is to get the source code. In a folder close to your heart, do the following:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

This will take some time depending on your internet connection. After it finishes, cd into the linux-next directory. You now have the source code! How could you build it you might wonder now. This is such a complex topic that it requires its own blog post! Stay tuned, and as always if you need help find me on FreeNode IRC as Levex in #fedora, #fedora-kernel, #fedora-devel and #fedora-hu as well.

Levente Kurusa
Fedora Project Hungary

Don’t fear the kernel!

I frequently see people getting scared when they try to do kernel development, because they see that there is no C library. Common false beliefs include but not limited to:

  1. No printf(), how would I debug my code?
  2. If I write mess, my hardware will blow up!
  3. Takes too much effort even to print out a string!

Here are my answers to them:

  1. Of course there is no printf(), because there isn’t any standard output. For debugging, we have printk(), which is (almost) exactly the same.
  2. No, the kernel will crash. Nowadays, the Linux Kernel is so evolved that it will take great efforts to cause hardware problems. Obviously, if you are a hardware vendor and you mess up your own hardware, then we can’t do anything for you. :-)
  3. It depends. If you start to write your own kernel, yes it does. The minimal kernel I could write that printed out a string was like 15 lines. But with Linux, and you really should develop that, you already have the already mentioned printk()

So, now that all the fear has been chased away, let’s talk about how could you contribute to the kernel. Well, it turns out that some very clever kernel developers already created the perfect tool to push you in the right direction. There is a file called ‘scripts/checkpatch.pl’. This file finds common code style issues in the code. However, there is a gotcha with this, you shouldn’t use this on normal, upstream code, because those patches do less good than bad, because they create noise. Checkpatch-patches are noise when trying to bisect a bug for example. Fortunately, there is a specific subsystem (folder), that contains files that should be checkpatch’d. This subsystem is called the Staging subsystem, and can be found in the drivers/staging/ folder.

Obviously, to be able to use this tool you need to have setup an environment which is able to build the kernel from the source code. It is pretty easy to do so and will be explained in a later post.

If you have any questions, please find me on Freenode IRC as Levex in #fedora, #fedora-devel and #fedora-hu as well.

My experience with KDE in the Google Code-In 2013


When I saw that KDE will be available for the Google Code-In I immediately knew that they would the organization I would like to work for during this event. I have used KDE in the past, but recently I have switched to XFCE for better performance. When the GCI started I moved back to KDE and I was surprised how much it had improved during my absense!

KDE? huh?

KDE is a desktop environment for the X Window System for Linux. KDE is vastly popular among the users of Kubuntu and Fedora-KDE. KDE comes with a bunch of preinstalled software: Marble, KDevelop, etc. It also has one major advantage over other desktop enviroments; it has a central git repository which makes development a load easier.

Marble? What is that?

Marble is a map viewer developed in C++. It is a swiss-knife map. It has views from the space, and the usual roadmap is in it as well. It has a very nice spherical projection also, where (as added bonus) you can view the stars, which is quite well made.

What did I do for Marble?

My first GCI task was to port the saving and restoring feature of the Qt Marble App to the KDE Marble App. This was quite easy, as it only involved creating the settings variables and then reading from and writing to them. My mentor was Earthwings, who was very happy to help me even with some dumb and pointless questions I had made. Earthwings even pointed me to the exact location where to make the changes. It was my first contribution to KDE. It was amazing.

My second Marble task involved relocating the popup window which shows up when you click on a placemark. It used to center the map on the placemark and show the popup next to it on the right. This was not right as for smaller screens this could go out of screen. My solution was to rotate the map so that the placemark is at the 1/4th of the screen. This resulted in the popup being approximately placed in the middle. This task was a bit harder, because I had to find out how marble works with its components and where to actually write the code.

KDevelop? I think I might know what it is.

So, KDevelop. Well it is an IDE. I will be very honest here. I have never thought KDevelop would be a good IDE. But after trying it out a bit more due to me developing it for a while I quickly realized that it is amazing. Simply amazing. So fast, so cool.

And what did I do for KDevelop?

My long dream was to work on an IDE, because I am a software engineer at heart and I love to make tools. So, with GCI I had the opportunity to work on one. I mostly did work on the Python support plugin called kdev-python. I have to stop here for a little. Python? I never wrote Python that much to write for a plugin for an IDE. Well, it turns out that by writing this plugin I managed to get a much wider understanding on how the Python language works. Another great point for GCI. So back to topic. Where was I? Ahh yes, kdev-python. Well my first task involving this plugin was to fix some problems with the built-in library support. I ended up adding the __add__ (and siblings) functions to most of the builtin classes so that the static analyzer of kdev-python understands what type a+b will be. As a bonus, I also added the docstring to it.

My second task with kdev-python was to fix the warning that showed up when the __new__ method’s first argument was named cls. kdev-python complained that it should be self but the standard is that it should be cls. Now fixed. :-)

The person that helped me here was scummos. He is awesome guy. He helped so much I couldn’t thank him enough. I truly suggest going to #kdevelop and asking for a task. It will make you learn and in the path you will learn something new.

As GCI is still going on, I will update this post with my other tasks.

LevOS4 progress report!
Ext2, ELF executables, mouting with VFS, /proc filesystem, syscalls and so on!
Awesome feeling when your application runs both on Linux and LevOS. :-)

Follow the project here: https://github.com/levex/osdev

LevOS4 progress report!

Ext2, ELF executables, mouting with VFS, /proc filesystem, syscalls and so on!

Awesome feeling when your application runs both on Linux and LevOS. :-)

Follow the project here: https://github.com/levex/osdev