[Sorry for the lame indentation]
* Proposal
For the Google SoC 2010 I propose to work on porting OpenInkpot to a currently unsupported ebook reader. Thus collecting the necessary hardware specifications and writing or porting the relevant Linux kernel drivers for OpenInkpot to be usable on the new hardware. For the port to be really successful I also consider hacking on the user-space part of the OpenInkpot distribution to be fundamental, ie. bug-fixing, enhancements and working on performance problems.
* Why would you like to work on the proposed project?
There are a few points that were important for my decision to apply to Google SoC with OpenInkpot:
Firstly, I like the technology you are working on and it seems to me that e-ink is now at a point where it really can offer a good experience to users. I don't own an ebook-reader myself (yet) but thinking about it from quite a bit of time now, I'm almost decided to buy one.
Secondly, running free and open source software on my new ebook reader would simply be awesome.
And then, clearly, the fun!. I just simply enjoy working with hardware and software. Furthermore I had a great experience as an intern at OLPC two years ago and would really love to participate in a cool project again.
* Experience in open source development
In 2007 I was one of the core software and hardware developers working at the IAS-Lab (Intelligent and Autonomous Systems Laboratory) at the University of Padova. We were able to develop an humanoid robot and later take part with it at the German-Open RoboCup 2007 event which was held in Hanover the same year. Unfortunately I cannot provide any link to the (closed) sources.
During the summer 2008 I was an inter at OLPC; my intern-project was about solving the performance problems that Sugar (www.sugarlabs.org) had at the time on the XO-1 (I can provide a end-of-internship summary on my work written by my mentor at OLPC on request). This is the only large-community FOSS project for which I did relevant contributions to this date.
Two small (side-)projects of mine that were developed during the internship at OLPC are:
- A lightweight /proc statistics gatherer and grapher http://dev.laptop.org/git/activities/picker/
- python module to collect the interpreter malloc stats from inside a script. This was useful, beside other things, to check how much memory was consumed at start-up by each of the modules imported by the Sugar Shell http://dev.laptop.org/git/users/rlucchese/python-allocstatsmodule/.git/
Some of the more recent one-guy projects of mine can be found at (explanations are on site): https://launchpad.net/~riccardo.lucchese
* Experience in GNU/Linux distributions development
I have built some .debs and .rpms in the past but never systematically. Just to test a patch on a different system or to keep some copy of a patched package around. Though, as far as I recall this was a bit boring but not so difficult.
I also used to write some custom init scripts for my machines. Perhaps it might be interesting to say that I once built Linux From Scratch. Though, I never did that a second time ;)
* Have you contributed to the Linux kernel?
I have never contributed to the Linux kernel before. But I have extensively worked before on microcontroller systems developing both hardware schematics and the necessary software. Though those were highly customized and relatively simple systems. Furthermore I collaborate (on a per-project basis) as a freelance professional with SimNumerica s.r.l. were I'm involved as a software engineer into developing cpu emulators and simulators for both digital and analogue electronic circuits.
It might make sense to add that I use to build my own kernel for my machines. Indeed, I always was fascinated by kernel hacking but never had any hitch to scratch that would take me more than rebuilding the kernel to get working what I needed too. Therefore, I never really had a good motivation to do any work on it. Though, I have read the whole of "Linux Kernel in a Nutshell" in the past and also started with "Linux Device Drivers" once but stopped when I realized I had no idea what to do with the knowledge.
Since there is some time before the start of SoC I would try remedying this by studying some of the relevant material. "Linux Kernel Development" from Robert Love is already in the queue of the books I want to read from a bunch of time now anyway ;)
* Commitment
Before the beginning of the SoC I will try to catch up with the relevant things I need to understand for a successful SoC. This might involve reading some kernel books or other suggested readings, or getting to know with the OpenInkpot distribution by bug-fixing. I plan to spend around 6-8 hours per week on this until the SoC starts.
From the 24-th of May I commit myself to work on the project for 40 hours per week. With two small `exemptions':
- Google SoC starts around one week before my lessons will
end. During this week there will be 2 week days when I'wont be able to work full time.
- Near the end of June we have our semester-closing exams in
Italy. Again, there will be a few days in that period when I won't be able to work full time.
Indeed, I think this should not be a big deal, but I felt it's important stating it clearly in advance. Please feel free to ask me more on this point.
I'm really motivated in conducting my proposal successfully until the end and since the payment from Google enables be working on something that I could not afford normally I commit to buy a second ebook reader during the SoC if the first bricks so that I can continue my work (and the fun can continue too !;).
* Tentative schedule
A possible SoC schedule is given in the following. Having never done something like this but being eager to learn I appreciate any input on this!
[week 1-5]
There is already a lot of interesting things we know on the Kindle DX. One of these is that attach to a serial port [1] is quite easy. So, it won't be a problem to have a ready development environment even before the SoC starts.
In the first weeks I should concentrate on porting and fixing the GPL sources released by Amazon [2]. Any missing but mandatory or nice-to-have kernel-space feature should be implemented during this time as well.
[week 6-7]
Get X.org and the OpenInkpot shell running. This might involve reverse-engenering some bits of the Kindle userspace.
An almost working display is the deliverable I would propose for the mid-term evaluation.
[week 9-12+]
Stabilize the source code and work on performance. Enhance the OpenInkpot `user experience' on large screen displays using the Kindle DX as a test case.
Code review, fix bugs, write relevant test cases and complete documentation.
I'm kind of a performance freak and should I be able to complete the port as in the timeline I'd be happy to work on perf, ie. profiling start-up, memory and cpu-usage; other directions could be discussed with the community as well.
Thanks, Riccardo
[1] http://www.mobileread.com/forums/showthread.php?t=49942
[2] https://www.amazon.com/gp/help/customer/display.html?ie=UTF8&nodeId=200203720
