diff options
author | Björn Stenberg <bjorn@haxx.se> | 2007-01-08 23:52:01 +0000 |
---|---|---|
committer | Björn Stenberg <bjorn@haxx.se> | 2007-01-08 23:52:01 +0000 |
commit | 6d4c19707ef95942e323cbdc89fbbfdbe45e7cc5 (patch) | |
tree | d11bbebc69df06d60970d05b4816e13d93602f2d /www/devcon/index.t | |
parent | 8cece5a745f30234bfced4becfd9dfe4ca1047d4 (diff) | |
download | rockbox-6d4c19707ef95942e323cbdc89fbbfdbe45e7cc5.tar.gz rockbox-6d4c19707ef95942e323cbdc89fbbfdbe45e7cc5.zip |
Splitting out www
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@11952 a1c6a512-1295-4272-9138-f99709370657
Diffstat (limited to 'www/devcon/index.t')
-rw-r--r-- | www/devcon/index.t | 132 |
1 files changed, 0 insertions, 132 deletions
diff --git a/www/devcon/index.t b/www/devcon/index.t deleted file mode 100644 index 8f0e1d78e7..0000000000 --- a/www/devcon/index.t +++ /dev/null | |||
@@ -1,132 +0,0 @@ | |||
1 | #define _PAGE_ Rockbox Developer Conference 2002 | ||
2 | #include "head.t" | ||
3 | |||
4 | <table align="right"><tr><td><a href="show.cgi?img4083.jpg"><img src="img4083t.jpg" alt="photo" border=0 width=200 height=150></a><br><small><i>Comparison of Recorder and Player</i></small></td></tr></table> | ||
5 | |||
6 | <p>Well, almost. :-) Björn, Linus, Daniel and Kjell sat down at Linus' house | ||
7 | friday night (2002-04-19) with our Archoses and had a long and fruitful discussion about software design. | ||
8 | Here are a few things that we discussed: | ||
9 | |||
10 | <h2>Application Programming Interfaces</h2> | ||
11 | |||
12 | <p>We want to try to stick to POSIX where these exist and are practical. The | ||
13 | reason is simply that many people already know these APIs well. Here are a | ||
14 | few which haven't already been defined in the code: | ||
15 | |||
16 | <h3>File operations</h3> | ||
17 | <ul> | ||
18 | <li>open | ||
19 | <li>close | ||
20 | <li>read | ||
21 | <li>write | ||
22 | <li>seek | ||
23 | <li>unlink | ||
24 | <li>rename | ||
25 | </ul> | ||
26 | |||
27 | <table align="right"><tr><td><a href="show.cgi?img4084.jpg"><img src="img4084t.jpg" alt="photo" border=0 width=200 height=150></a> | ||
28 | <br><small><i>Contest: Spot the development box!</i></small></td></tr></table> | ||
29 | |||
30 | <h3>Directory operations</h3> | ||
31 | <ul> | ||
32 | <li>opendir | ||
33 | <li>closedir | ||
34 | <li>readdir | ||
35 | </ul> | ||
36 | |||
37 | <h3>Disk operations</h3> | ||
38 | <ul> | ||
39 | <li>readblock | ||
40 | <li>writeblock | ||
41 | <li>spindown | ||
42 | <li>diskinfo | ||
43 | <li>partitioninfo | ||
44 | </ul> | ||
45 | |||
46 | <p>We also decided that we will use the 'newlib' standard C library, | ||
47 | replacing some functions with smaller variants as we move forward. | ||
48 | |||
49 | <h2>Multitasking</h2> | ||
50 | |||
51 | <p>We spent much time discussing and debating task scheduling, or the lack | ||
52 | thereof. First, we went with the idea that we don't really need "real" | ||
53 | scheduling. Instead, a simple "tree-task" system would be used: A | ||
54 | main-loop, a timer tick and a "bottom half" low-priority interrupt, each | ||
55 | with an event queue. | ||
56 | |||
57 | <p>Pretty soon we realized that we will want to: | ||
58 | |||
59 | <ol style="a"> | ||
60 | <li> Use a timer tick to poll disk I/O (assuming we can't get an interrupt) | ||
61 | <li> Perform slow disk operations in both the MP3->DAC feeder and the user | ||
62 | interface, sometimes at the same time. | ||
63 | <li> Not lock up the user interface during I/O. | ||
64 | </ol> | ||
65 | |||
66 | <table align="right"><tr><td><a href="show.cgi?img4086.jpg"><img src="img4086t.jpg" alt="photo" border=0 width=200 height=150></a> | ||
67 | <br><small><i>A stack of "virgins"!</i></small></td></tr></table> | ||
68 | |||
69 | <p>At the same time, we agreed that we should not walk into the common trap | ||
70 | of engaging in "job splitting". That is, to split up jobs in small chunks | ||
71 | so they don't take so long to finish. The problem with job splitting is | ||
72 | that it makes the code flow very complex. | ||
73 | |||
74 | <p>After much scratching our collective heads over how to make a primitive | ||
75 | "three-task" system be able to do everything we wanted without resorting | ||
76 | to complex job splitting, we finally came to the conclusion that we were | ||
77 | heading down the wrong road: | ||
78 | |||
79 | <p><blockquote> | ||
80 | <b>We need threading.</b> | ||
81 | </blockquote> | ||
82 | |||
83 | <p>Even though a scheduler adds complexity, it makes the rest of the code so | ||
84 | much more straight-forward that the total net result is less overall | ||
85 | complexity. | ||
86 | |||
87 | <p>To keep it simple, we decided to use a cooperative scheduler. That is, one | ||
88 | in which the threads themselves decide when scheduling is performed. The | ||
89 | big gain from this, apart from making the scheduler itself less complex, | ||
90 | is that we don't have to worry as much about making all code "multithread | ||
91 | safe". | ||
92 | |||
93 | <p>Affording ourselves the luxury of threads, we soon identified four basic | ||
94 | threads: | ||
95 | |||
96 | <ul> | ||
97 | <li>Disk thread, performing all disk operations | ||
98 | <li>UI thread, handling the user interface | ||
99 | <li>MP3 feed thread, making sure the MAS is fed with data at all times | ||
100 | <li>I2C thread, handling the sometimes very relaxed timing of the I2C bus | ||
101 | </ul> | ||
102 | |||
103 | <p>Threads use message passing between them and each have a message queue | ||
104 | associated to it. | ||
105 | |||
106 | <table align="right"><tr><td><a href="show.cgi?img4089.jpg"><img src="img4089t.jpg" alt="photo" border=0 width=200 height=150></a> | ||
107 | <br><small><i>There's much fun to be had with these things!</i></small></td></tr></table> | ||
108 | |||
109 | <p>In addition to the threads, we need a timer interrupt with the ability to | ||
110 | send messages to threads at specific intervals. This will also be used to | ||
111 | scan the keys of the jukebox and handle key repeat detection (when a key | ||
112 | has been pressed for a number of ticks). | ||
113 | |||
114 | <p>None of these things are, of course, written in stone. Feel free to | ||
115 | comment, discuss and argue about them! | ||
116 | |||
117 | <p>We are currently 89 subscribers to this list. If you want to get more | ||
118 | deeply involved in what's going on, I encourage you to: | ||
119 | |||
120 | <ul> | ||
121 | <li>Subscribe to the rockbox-cvs list, to see all code that goes in. | ||
122 | <li>Join the #rockbox channel on irc.openprojects.net. There are always a | ||
123 | couple of us in there. | ||
124 | </ul> | ||
125 | |||
126 | <p>I have written a set of guidelines for contributing code to the project. | ||
127 | Take a look at them in CVS or here: | ||
128 | <a href="http://bjorn.haxx.se/rockbox/firmware/CONTRIBUTING">CONTRIBUTING</a> | ||
129 | |||
130 | <p>/Björn | ||
131 | |||
132 | #include "foot.t" | ||