I know I know I should have done it before...... But there is an advice "If you don't have to do it, don't bother"....
Why did I do it now?
Well, several days ago Linux Foundation
posted an article that they are funding three Linux internships through the Outreach program for women ran by
GNOME Foundation.....
I planned to apply for OpenStack firstly but I was making my decision till the last minute when I saw Linux Foundation's call...
I decided in a matter of minutes to send first mail to Sarah Sharp (she works for Intel as a kernel developer and she is responsible for USB 3.0 maintenance)...
So she helped me to write my application for opw and send it to GNOME official list. I also had to join the kernel-opw google group (collaboration group for Linux kernel interns)....
After that I had to do first assignment - create the first patch and send it to the opw-kernel google group not the main kernel mailing list since this is not "the real deal" at least not yet...
Oh boy, it seemed easy while reading this
tutorial
But it was not easy, at least not for me and my computer (You'll see later what I am talking about.)
First of I had to set up
an environment so I could actually do some Linux Kernel Hacking. For those of you who are not familiar with Kernel development - there is a whole set of rules how to contribute to Linux development.
They even have their own style of coding - read it first before sending the first patch (It will save you a lot of nerves).
So, setting up an environment was a big deal to me. I had to learn Git basics so I could actually download Linus' branch of newest version of kernel in the special directory.
O.K. that went well. It took my computer for cca 2 hours to download it (that was a surprise for me)
When the kernel was downloaded it was time to copy old kernel config file (2.6.x.x-generic) to the new kernel folder as .config file, and then press make olddeconfig to record changes
(Me the n00b) firstly skipped make olddeconfig command and pressed make instead... What happened then?
Good Golly - compiling didn't went smoothly because I had to answer questions what do I want to include in my new kernel/what I don't want to include/what should be as a module...... Oh Boy ... I was answering for almost an hour but then I started to feel like an idiot and I asked on opw-kernel group how long does this take? Greg Kroah-Hartman told me that I forgot to do make olddeconfig and he was right.... Yes Greg Kroah-Hartman is one of the mentors for Linux kernel interns and he is really cool...
So that saved me a lot of effort... I did make olddeconfig and then make and compiling went on its own.
But my 8 year old computer with 2.40 Ghz Intel Celeron and 128 MB of RAM was not happy... It took almost 6-7 hours to compile the kernel... I slept only 3 hours from Sunday to Monday because I was too eager to see what will happen next.
I left computer working and when I woke up it was done, with low disk space message, but it was done.... After that I installed the new kernel - which worked fastly unlike compiling...
Environment was set including Git, mutt, Vim, e-mail setup so I can send a patch from the terminal....
Creating the first patch was not easy at the first but when you start reading tutorials on KernelNewbies site and other tutorials you get quite comfortable.
First thing before sending a patch is to read Patch philosophy and coding style rules.... If you brake the rules and if you try to commit the patch it is most likely not to be accepted...
After you have read those, get familiar with Git's basic commands.
For a start you need to know how to switch between different kernel branches. You can see under which branch you are by typing git branch
You are NOT suppose to do changes in the Linus' branch which is called master as I figured it out. You have to create your own branch. So do this --- git branch NameTheBranchAsYouLike
To switch to that branch just type git checkout NameTheBranchAsYouLike
You can use git branch command again to see if you really are under your branch (you'll see an asterisk next to your branch's name)
Now it's time to do some hacking.... What to hack? Well, If you have read KernelNewbies tutorial you have noticed that there is also staging branch which has a lot of drivers to clean up (they have either bad code styling or some other errors that should be fixed)
You can find them by just typing path find drivers/staging -name TODO (TODO means that they need to be fixed)
So, pick one, open it with cd commnd and you'll see a lot of files...
That's a problem now... How the heck are you going to know what should be fixed?
Well, Kernel developers thought about it too and they created script called checkpatch.pl which you can find under /linux/scripts folder
So, to check some file for errors (or that you could know what to fix) you have to write following for example, you can choose some other driver and a file
./scripts/checkpatch.pl --file -f drivers/staging/comedi/drivers/pcmda12.c
After script ran through the file you will be prompted with warnings - you will get number of line and explanation what should be fixed
At this stage I recommend that you open another terminal window and open that file in Vim editor - so you can fix file on one side and run the script on the other side until you solve all problems and get 0 warnings and 0 errors.
When you came to the stage with 0 warnings and 0 errors and a note that file is ready for submission you have to type the following (which I forgot to do and I sent patch without it - luckily Greg warned me)
make drivers/staging/comedi/drivers/pcmda12.o
This is the real check up - so you could know that you didn't brake something... Although you fixed the file with help of checkpatch.pl that doesn't mean that it is really fixed and that it will be built into kernel properly....
O.K. after that is done you can check your changes by typing git status and git diff ... Git remembers all changes you did (literally ALL of them - pretty cool ha)
Time to commit the patch (If you didn't set your e-mail and editor do that by following the KernelNewbies tutorial - it is nicely written there)
So type git commit drivers/staging/comedi/drivers/pcmda12.c
You will be prompted with Vim (Do NOT erase anything in there) just start writing by following the "Patch Philosophy" what does your patch fix, don't break the rule of 80 characters)
Save it and get out of the Vim editor
You will still have to do the following so you could ship your patch via mutt (everything with patching in kernel world works via mailing lists)
git format-patch -o /tmp/ HEAD~
mutt -H /tmp/0001-<whatever your filename is> (you will see the name after the command above)
After you pres mutt ....... you will be prompted with e-mail tool (press no) and then you will have to type an e-mail where are you sending your patch to.... Send it to yourself first just in case (good recommendation from kernel devs)
Then do the mutt ......... again and send it to the real list you have to...
You will be able to edit your patch in mutt but I don't recommend that... What is done is done by Git
My first patch was real trivia - fixing wrong indentation
here it is and how it looks like
Fixes indentation for file pcmda12.c
Wrong indentation was found at:
line 83
line 102
Patch also fixes comments readability
Signed-off-by Jasna Bencic <bencic24@gmail.com>
---
drivers/staging/comedi/
drivers/pcmda12.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/comedi/drivers/pcmda12.c b/drivers/staging/comedi/drivers/pcmda12.c
index 0a5e663..4c0b85b 100644
--- a/drivers/staging/comedi/drivers/pcmda12.c
+++ b/drivers/staging/comedi/drivers/pcmda12.c
@@ -81,7 +81,7 @@ static void zero_chans(struct comedi_device *dev)
ASIC chip to defaults */
int i;
for (i = 0; i < CHANS; ++i) {
-/* /\* do this as one instruction?? *\/ */
+ "/* do this as one instruction?? */"
/* outw(0, LSB_PORT(chan)); */
outb(0, LSB_PORT(i));
outb(0, MSB_PORT(i));
@@ -100,8 +100,9 @@ static int ao_winsn(struct comedi_device *dev, struct comedi_subdevice *s,
* very useful, but that's how the interface is defined. */
for (i = 0; i < insn->n; ++i) {
- /*do this as one instruction??*/
- /*outw(data[i], LSB_PORT(chan));*/
+
+ "/*do this as one instruction??*/"
+ "/*outw(data[i], LSB_PORT(chan));*/"
/* Need to do this as two instructions due to 8-bit bus?? */
/* first, load the low byte */
Nothing special but it is my first patch....
Will I be accepted as a Linux Kernel Intern, I don't think so, I still have to learn a lot and I realized that this for now is way out of my league.....
I learned a lot for these past 2 days, I'm not afraid to poke the kernel anymore and to break stuff.... It is pretty cool.....
Now I have a new learning environment called drivers/staging/ -name TODO where I can lurk the code and think how to fix it and when I'll be ready I'll send patches to the real kernel list and wait for Linus to say how horrible it is :D
You know Linus, he is strict and strong with his language when talking with kernel developers (even he admitted it)....
I really wanted to meet Linus this way as a Linux Foundation's intern but maybe some other time in some other place.....