From: Thomas Martitz <thomas.martitz_at_student.htw-berlin.de>
Date: Mon, 24 May 2010 13:33:03 +0200

Hi guys,

I've been quite busy this week and so I haven't really managed to get
further.

But I have looked into what's left in uisimulator/common and a few
questions arised which I would like to discuss a bit about:

1) io.c, currently the simulator hides the rest of the filesystem and
only shows the current working dir in the file browser (by wrapping file
I/O functions). I think we don't want that for RaaA but I also doubt we
want to expose the entire filesystem. What came into my mind was
(assuming Rockbox is installed into some program dir) that the file
browser would show the program dir (i.e. the working dir) where .rockbox
sits and to show $HOME via a "mounted drive", e.g. similar to how
microSDs are handled currently; this way you could easily access the
music folders (and pics, videos) independently of the installation dir.
However, that doesn't work for music outside the $HOME dir. How do we
want to handle this cases? We could use the ability to name the .rockbox
dir differently or change the "root" directory dynamically.

2) firmware/target/hosted/lcd-charcell.c uses some functions from
uisimulator/common, that's not very clean w.r.t. to the target tree
idea. but the code under uisimulator/common is independant of sdl and
really only serves simulation of charcell displays. What would be the
best way to clean it up? Cleaning up is not critical at this point I
think but it should happen at some point, I'm just not sure how.

3) Soon I'll be skimming through the sources to check #ifdef SIMULATORs
for whether they also apply for RaaA. I will need some defines that
separate a RaaA build from the a real target build and from the
simulator. RaaA will not define SIMULATOR so that point would be pretty
clear, but for the first something needs to be invented. I thought of a
new CONFIG_PLATFORM (which could be PLATFORM_NATIVE and
PLATFORM_HOSTED). The simulator would #define CONFIG_PLATFORM
PLATFORM_HOSTED, but we need to take care to not exclude parts of the
code that runs in the sim but not on RaaA (for the purpose of simulating
our code). We could also re-use CONFIG_CPU which is not used in the sim,
which would be more in line with the existing targets but would maybe be
confusing as RaaA won't be cpu dependent. Do you have other ideas?

The above points need to be worked out sooner or later (1 and 3 more
sooner rather than later) so I would like some input from you guys.

Best regards.
Received on 2010-05-24