Submitting a Linux kernel patch

Naikon

Just thought at least one person here might find these interesting. Some fixes are trivial, others not. If you don't
code, documentation help is also very important. It's quite cool that anyone can help improve the Linux kernel.

http://www.tuxradar.com/content/newbies-guide-hacking-linux-kernel
http://www.youtube.com/watch?v=LLBrBBImJt4

Eliot Rosewater

Have you done much yourself Naikon?

I found a rather obscure bug in the gnome-about-me package in Ubuntu this week. It had already been reported in January but the report message was ambiguous; a proper report was sent in a few weeks ago. The problem was fixed (not be me!) on Tuesday and will be in the updates next week. It was my first glimpse of seeing the open-source philosophy work in relation to errors.

It also made me realize that in many ways the OS gets better and better as time goes on, with all these little creases being ironed out.

Naikon

I've submitted some minor bug reports but that's about it:o I just feel I am at a stage now where I feel I could leverage my coding knowledge to give support to some well used open source software. It's the least I could offer when you consider I am running an Enterprise capable distro for nothing. I am currently getting into the hang of writing POSIX applications myself, things like simple userland clones like ls, cat etc, but I feel helping out the kernel devs directly might be beneficial. I am no wizard, but I am still learning:cool: My primary real motivation? I feel like I won't keep up purely relying on college work. Beyond the basics and CRUD applications, I don't feel like I am learning a whole of useful skills besides my own project work.

But enough about me. Anyone can always help out in some way. The community is one of the best traits of the Open Source community in general. You don't really find it as much in commercial commodity efforts like OSX/Windows. Just my 0.02$

/rambling

Eliot Rosewater

I'm only doing a degree in Maths myself, although this year (first year) 25% of my modules were computer based. Next year only 1 out of 12 will be. So I'm not convinced if I will ever have the coding skills required to contribute.

One of the courses I did this year was Programming in C. After doing it I downloaded the source code of the GNU Core Utils (ie the command line programs like "ls" and "cd") and perused through them. I was pretty lost. :pac:

So I'll have to find some other way to help out!

Khannie

Eliot Rosewater wrote: »

After doing it I downloaded the source code of the GNU Core Utils (ie the command line programs like "ls" and "cd") and perused through them. I was pretty lost. :pac:

I would say you're looking at several years industry experience before you could make head nor tails of that code so don't be disheartened.

Naikon

Nah, don't get bogged down by looking at the GNU sources. Their clones of common utilities are far more complex than required for learning the concepts. Look at the code below, it's basically a barebones ls implementation. It requires alot more work to make it actually usable. but the concepts still apply. You can get lost in the complexities of commercial grade stuff, but sticking to the most important fundamentals is the only way to learn if you don't have years of hard graft behind you at the moment.

/*Original code from APUE 2nd edition*/
#include <sys/types.h>  
#include <dirent.h> 
#include <stdio.h> 
#include <stdlib.h>  

int main(int argc, char **argv) {
      
      /*dirent pointer points to file specific fields(name for example)*/
      struct dirent *dirp;  
      DIR *dp;

      fprintf(stderr, "usage: %s dir_name\n", argv[0]);    
      exit(1);    
      }   
      /*Arg[1] is our first argument, use as directory to display contents of*/
      if ((dp = opendir(argv[1])) == NULL ) {    
      fprintf(stderr, "can't open '%s'\n", argv[1]); 
      exit(1); 
      }     
      /*Keep iterating until (dirp = readdir(dp)) points to NULL*/
      while ((dirp = readdir(dp)) != NULL )    
      printf("%s\n", dirp->d_name);    /*Print name field of file*/
      closedir(dp);   /*Close file handle*/
      exit(0);  
     
  }

All this is doing is declaring two pointers, one of type DIR(*dp) for use as our file handle, and *dirp which used in conjunction with the readdir() function to read the contents of a directory. It's a really nice example of how simple the whole Unix concept is. Everything in here is not tied to a particular filesystem, thus ensuring portability. Unix interfaces care only about streams of bytes. It's not like Windows where file associations are handled for each file type at the OS level. It's up to the applications to make use of that information generally. POSIX interfaces are the closest we have to a truely standardised OS.

This stuff is heavy, so don't get too bogged down at first. Working through the code and writing similar code is the key. It's a shame most colleges that teach computer subjects(not just computer courses)disregard the basics of systems programming for yet another frontend to a database TM. Nothing wrong with that at all, but this stuff is way, way more interesting. At least for me : )

ntlbell

Eliot Rosewater wrote: »

I'm only doing a degree in Maths myself, although this year (first year) 25% of my modules were computer based. Next year only 1 out of 12 will be. So I'm not convinced if I will ever have the coding skills required to contribute.

One of the courses I did this year was Programming in C. After doing it I downloaded the source code of the GNU Core Utils (ie the command line programs like "ls" and "cd") and perused through them. I was pretty lost. :pac:

So I'll have to find some other way to help out!

If you did want to "give something back" there's plenty of ways to do so without knowing how to code.

Even something as small as fixing a typo in a man page for example, or submiting the bug in the first place are all very helpful.