Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project

[Lars Noschinski]

* Jiri Kosina <jkosina@xxxxxxx> [08-05-31 11:48]:
> I fully agree, but my impression is that this really is not going to be 
> easy. Fixing bugs definitely is a good way to start kernel coding -- it 
> forces you to understand the internals of the source, get used to the 
> coding style by reading the code, etc. Unfortunately, it's simply not very 
> attractive for newcomers.
>
> For example -- I am leading a seminar at university, oriented at linux 
> kernel internals. I provide the possibility to students either to
>
> - write some stand-alone interesting kernel project
> - fix a few non-trivial bugs in kernel bugzilla
> - chose any part of a kernel, learn how it works, and present this to 
>  other seminar attendees
>
> The feedback I often get from students (and these guys are studying 
> computer science) is
>
> - writing some wholy new interesting kernel project is usually too 
>  complicated (both coming with an interesting idea for a project, and 
>  doing the coding itself)
> - fixing random bugs from kernel bugzilla is boring (spending 10 hours 
>  looking for missing '=' doesn't really attract them)
>
> So in overwhelming majority of cases, they just chose the presentation.

From my own experience: Last semester, I participated in a "Linux Kernel
Hacking Lab" which involved some smaller tasks (write a module which
presents a circular buffer in /proc; the same as char device; write
a very minimalistic file system, extend it to do something resembling
journalling, ...) and a larger project.

The first two tasks were easily done by reading Linux Device Drivers;
but after the file system task (2 weeks), more than half of the group
dropped out; probably because to get this task done you needed to dig at
least in the minix code.

The project I was later involved on was writing a file system, which
stores blocks with the same content only once. In a two months period
(with other lectures to attend to), we managed to produce such a thing;
but it was very unreliable (which reminds me, I am supposed to publish
the results of this project here)

Most problems resulted of a combination of not enough documentation
(filesystem/page cache/block device interaction) and "not digging deep
enough, so the kernel does not really do what we expected".

So, the code produced in this learning phase is not usable; but I
learned a lot from this. Restarting from scratch now would probably
yield some working code.

At least, know I understand why Linux has such a high rate of changes ;)

> All I want to say is that I could very well imagine that a lot of 
> newcomers will find "hey, feel free to crawl through bugzilla and fix 
> whatever you are able to fix" very non-attractive.
> Not that I have any better idea right now, though.

I probably would not have attended a lab titled like this ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/