From: Nils Wallménius <nils.wallmenius_at_gmail.com>
Date: Tue, 25 May 2010 15:18:18 +0200

On Mon, May 24, 2010 at 1:33 PM, Thomas Martitz
<thomas.martitz_at_student.htw-berlin.de> wrote:
> 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.
>

Hi, it sounds like you are making good progress!

1) I don't really see why you would want to limit the file browser to
just a few dirs, rockbox has traditionally been about user freedom so
i would suggest letting them browse the entire fs.

3) I think your CONFIG_PLATFORM idea is good but would not like reuse
of CONFIG_CPU for something else. So i would suggest adding a #define
such as APPLICATION that only RaaA defines and that both sim and RaaA
defines the PLATFORM_HOSTED.

Nils
Received on 2010-05-25