From 6365d0e6ccd891da7812c6c7d7b0f8eadf414b30 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B6rn=20Stenberg?= Date: Mon, 27 May 2002 14:28:44 +0000 Subject: devcon git-svn-id: svn://svn.rockbox.org/rockbox/trunk@753 a1c6a512-1295-4272-9138-f99709370657 --- www/devcon/index.t | 132 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 www/devcon/index.t (limited to 'www/devcon/index.t') diff --git a/www/devcon/index.t b/www/devcon/index.t new file mode 100644 index 0000000000..8f0e1d78e7 --- /dev/null +++ b/www/devcon/index.t @@ -0,0 +1,132 @@ +#define _PAGE_ Rockbox Developer Conference 2002 +#include "head.t" + +
photo
Comparison of Recorder and Player
+ +

Well, almost. :-) Björn, Linus, Daniel and Kjell sat down at Linus' house +friday night (2002-04-19) with our Archoses and had a long and fruitful discussion about software design. +Here are a few things that we discussed: + +

Application Programming Interfaces

+ +

We want to try to stick to POSIX where these exist and are practical. The +reason is simply that many people already know these APIs well. Here are a +few which haven't already been defined in the code: + +

File operations

+ + +
photo +
Contest: Spot the development box!
+ +

Directory operations

+ + +

Disk operations

+ + +

We also decided that we will use the 'newlib' standard C library, +replacing some functions with smaller variants as we move forward. + +

Multitasking

+ +

We spent much time discussing and debating task scheduling, or the lack +thereof. First, we went with the idea that we don't really need "real" +scheduling. Instead, a simple "tree-task" system would be used: A +main-loop, a timer tick and a "bottom half" low-priority interrupt, each +with an event queue. + +

Pretty soon we realized that we will want to: + +

    +
  1. Use a timer tick to poll disk I/O (assuming we can't get an interrupt) +
  2. Perform slow disk operations in both the MP3->DAC feeder and the user + interface, sometimes at the same time. +
  3. Not lock up the user interface during I/O. +
+ +
photo +
A stack of "virgins"!
+ +

At the same time, we agreed that we should not walk into the common trap +of engaging in "job splitting". That is, to split up jobs in small chunks +so they don't take so long to finish. The problem with job splitting is +that it makes the code flow very complex. + +

After much scratching our collective heads over how to make a primitive +"three-task" system be able to do everything we wanted without resorting +to complex job splitting, we finally came to the conclusion that we were +heading down the wrong road: + +

+ We need threading. +
+ +

Even though a scheduler adds complexity, it makes the rest of the code so +much more straight-forward that the total net result is less overall +complexity. + +

To keep it simple, we decided to use a cooperative scheduler. That is, one +in which the threads themselves decide when scheduling is performed. The +big gain from this, apart from making the scheduler itself less complex, +is that we don't have to worry as much about making all code "multithread +safe". + +

Affording ourselves the luxury of threads, we soon identified four basic +threads: + +

+ +

Threads use message passing between them and each have a message queue +associated to it. + +
photo +
There's much fun to be had with these things!
+ +

In addition to the threads, we need a timer interrupt with the ability to +send messages to threads at specific intervals. This will also be used to +scan the keys of the jukebox and handle key repeat detection (when a key +has been pressed for a number of ticks). + +

None of these things are, of course, written in stone. Feel free to +comment, discuss and argue about them! + +

We are currently 89 subscribers to this list. If you want to get more +deeply involved in what's going on, I encourage you to: + +

+ +

I have written a set of guidelines for contributing code to the project. +Take a look at them in CVS or here: +CONTRIBUTING + +

/Björn + +#include "foot.t" -- cgit v1.2.3