There were three days of technical presentations, with a Keynote Presentation in the end of each day and several receptions for chat and interaction in the evening.

I was most interested in the Linux Kernel presentations, but I noticed there were a lot of IoT and Cloud services presentations, since these represent some of the trends in administration lately.

I joined the round 9 and round 10 interns, together with the coordinator of the program, Julia Lawell to constitute a panel on Linux Kernel Internship Reports, but this happend only on the 3rd day.

The group coming from Romania was pretty large, we had 3 interns that gave presentations, some teaching assistants and professors from my university and also former interns in the internship program. Going to LinuxCon is somehow a tradition and the group becomes larger and larger every year.

One of my favourite presentations was the one given by Michael Kerrisk (yes, the author of The Linux Programming Interface) on seccomp and the current capabilites of it, such as selective permission and investigation of system calls that a process can make. The presentation went through the beginnings of seccomp and then focused on Berkeley Packet Filter virtual machine, implemented in the kernel. Michael proposed some examples of filters and also integration of a program with BPF filters, which made the presentation more hands-on and provided high interaction with the public.

I also attended Harald König’s presentation on Using strace to understand bash, which were mostly things I’ve known before, such as wildcards, quoting and some nice examples of strace investigation, such as seeing what login scripts have been executed in bash.

Another presentation that I really liked was from the guys of Free Electrons. I’ve been using the documentation of free electrons a lot, but I had no idea they are just 9-10 people working in the company, with such a great contribution of embedded Linux.

The second day closed with Fireside Chat, in which Dirk Hohndel interviewed Linus Torvalds and it was for sure what everyone had expected to see. They talked about kernel security, future plans for Linux, the trouble of finding maintainers, not only contributions and also what would be the next project of Linus or if he’s thinking of one. Linus had a particulary funny answer, suggesting that he created Git, Linux because no one else provided him with what he needed, adding that: "I’d much rather coast along and be lazy. Anytime I need to start a new project, that’s a failure for the rest of the world".

There was also room for the famous joke with Linus being hit by a bus, especially since in the UK they drive on the left side.

I also had the chance to meet Linus Torvalds and GregKH in person at the ending reception, held in the Guiness Storehouse in Dublin. Pretty awesome!

On the 3rd day I had the opportunity to present my work over the summer on the Linux Kernel Internship Panel, introduced by Julia Lawell, the coordinator of the program. Meeting the other interns, sharing experiences and impressions on the internship and also meeting developers that I’ve seen only on mailing lists made me see what truly is the Linux open source community.

Since the days were so busy with presentations and all, I didn’t have the time to go visit too much, but Dublin has the air of an industrial and also modern city with pittoresque pubs in which one can have a nice time. I really enjoyed it.

All in all, attending LinuxCon in Ireland was technically enligthening and fun, no need to mention the beer!

Everything you have to know for working on the Linux Kernel has been created by Linus Torvalds. That is the Linux Kernel itself and git.

Oh.. almost everything. Linus seemed content with the C programming language.

Linux kernel is currently under a mixture of code following C89/C90 and C99 standards. By taking a look into the Makefiles you’ll find the majority compiling with -std=gnu89, that is to say they are using the C89/C90 standard with some extensions.

If you ever wonder why they still allow errors like these “error: ‘for’ loop initial declarations are only allowed in C99 mode” Linus has given a legitimate answer which says that it’s mainly a standard for keeping code clean and easy to follw through the sources.

Why git? CVS and SVN seemd a terrible idea at that time as a version control system and what do you do when you really don’t like a tool? That’s right, you’ve probably guessed.

So, the step 0 would be to setup git and download the latest kernel version. Also,make sure to fetch the changes every time you start working on something, so that your patches won’t be rejected when the maintainer tries to apply them on the tree.

The next step would be to check the kernel coding style, which is generously explained in the Linux Documentation and set your editor according to them.

Yes, apart from the ultimate error which is breaking the build, the second ultimate would be mixing tabs and spaces! Linux Kernel goes on the dark side of tabs (no cookies, sorry), with extra-spaces when aligning parameters.

Step 2: My code is compiling

Depending on your processor, the building time might vary, but it will still take a bit. In the meantime you can read Linux Device Drivers or have a little bit of fun reading some statistics on how many times words like ‘bastard’ and ‘crap’ appear in the Linux Kernel source code. You can also grep it for more fun.

Step 3: Make a small change and send it

The reason for which you that to pass through all these preparatory steps was to finally get some changes committed. You can start with a simple change such as adding error check on some devices or clean some code that needs refactoring.

Linux does not use pull requests (at least not on github ) as a means of merging changes, but e-mailed patches. That means you have to find the propper maintainter - the get_maintainter.pl in the /scripts folder will help you to do so - and e-mail him your patch. You’ll find a set of standards for that, too.

Just keep in mind to compile your module and test after making even the tiniest change, because if something goes wrong you will have wasted your time and the maintainer’s time on sending a patch that cannot be applied, or worse, breaks the build.

Even if sometimes paying attention to all these rules involving proper coding, commit standards and e-mail formatting seems to be a little bit overwhelming by taking more time than the actual code changes, with time it will become quite natural. After all, in a development area of aproximately 1,500 people working from remote areas, the needs of having a rather fixed set of rules is indeed well-justified.

Step 4: Become a regular contributor

After sending a series of first patches, you’ll be proud to be officially known as a Kernel Newbie! You can choose a project to focus on, talk to people in the community, hang out on the IRC channels and so on.

Keep in mind that, if there’s something you cannot manage, it is very likely to find someone on the IRC channels more than happy to give you a hand. You don’t have to become like this guy!

For an official tutorial, please follow this link.

Copyright on the images goes to https://xkcd.com, if not specified otherwise.

I haven’t been involved too much into open source development and I’ve always wished to be, so that when I heard the program was opened, I saw it as the perfect chance to start contributing and be part of a community.

The process of selection lasted from the end of February until April, time in which I’ve got accustomed with the work environment, kernel development practices and wrote a few patches for a project I liked. I did my best in trying to know the project as much as I could and finally got accepted!

Why Linux Kernel?

I find operating systems the most fascinating subject in computer science and what better way to broaden my knowledge than actually contributing to the Linux Kernel? Apart from that, the penguin is nice.

What is IIO?

IIO stands for the Linux Industrial I/O Subsystem which deals with drivers for small devices, analog or digital such as sensors (pressure, light, temperature), accelerometers , ADCs, DACs and others. The IIO module has been in the upstream linux kernel since v2.6.32, that would be around 2009 and supports more than 200 iio device drivers [1]. More blog posts on this subject and the iio architecture are coming in the next weeks, as I am currently investigating and reading in the field.

There were several proposals for the projects on this round, which you can find here. I chose the IIO dummy driver mentored by Daniel Baluta and Octavian Purdila, which acts as a sort of template for writing iio drivers, but which is far from clean. My main responsability is to solve all the problems related to this dummy driver and get it out of staging.

All in all, it’s going to be an interesting summer, with a lot of challenges I can hardly wait to solve!