Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: [RaaA] Move SDL stuff to target tree

Re: [RaaA] Move SDL stuff to target tree

From: Thomas Martitz <thomas.martitz_at_student.htw-berlin.de>
Date: Sun, 16 May 2010 19:06:44 +0200

Am 16.05.2010 18:24, schrieb Karl Kurbjun:
> On Sun, 2010-05-16 at 16:32 +0200, Thomas Martitz wrote:
>
>> Am 16.05.2010 16:06, schrieb Dave Chapman:
>>
>>> Thomas Martitz wrote:
>>>
>>>>> My understanding of the purpose of RaaA is that it would use less
>>>>> and less of the Rockbox firmware code as time went on. Development
>>>>> of the sim should go in the opposite direction - using more and more
>>>>> Rockbox code.
>>>>>
>>>>
>>>> No, I don't think RaaA aims to use less and less Rockbox code. It's a
>>>> port of Rockbox afterall.
>>>>
>>> I said "Rockbox firmware code". So what _is_ RaaA if it's not about
>>> using less Rockbox code than a "real" Rockbox ?
>>>
>>>
>> I sad it, it's a rockbox port. It will use as much of the (entirely,
>> including firmware) Rockbox code as possible. Exactly in the same way
>> how the other ports do it. That's why it was moved into the target tree.
>> Only the target specific code is there, the rest is re-use of Rockbox code.
>>
>>
>>>>> I'm also not convinced that changing some #ifdef SIMULATOR lines to
>>>>> use things like HAVE_SDL or HAVE_SDL_AUDIO makes the code for the
>>>>> simulator better. IMO it makes it harder to see the places where
>>>>> the sim differs from the target it's simulating (it still differs in
>>>>> the same way, it's just obfuscated more).
>>>>>
>>> Can you respond to this?
>>>
>> Frank Gevaerts described it well. We have a single place, sim.h, where
>> you look for defines which differ from the target. It's no more or less
>> obfuscated.
>>
>>>
>>>>> As an example of the different purposes of the sim and RaaA, the SDL
>>>>> button driver for RaaA should expose all buttons to the apps/ part
>>>>> of Rockbox (especially if there is a full keyboard on the device).
>>>>> The SDL button code for the sim should (although it doesn't
>>>>> currently) provide simulation of the hardware buttons (and/or
>>>>> touchscreen and remote) on the real device, including things like
>>>>> mechanical and electrical limitations. Other buttons are used for
>>>>> events such as USB insertion/removal.
>>>>>
>>>> That's not going to change. The parts that are simulating a target
>>>> override the SDL app parts, e.g. by including a different
>>>> button-target.h. We never simulated mechanical and electrical
>>>> limitations and that's not going to change.
>>>>
>>> Why is that not going to change? Who decided that wasn't a desirable
>>> feature of the sim?
>>>
>> Anyway, I don't see how target-tree'ifying would prevent doing that.
>>
>>
>>>
>>>> We want to run code which
>>>> compiles for a target on a more convinient system (simulate), not
>>>> emulate the target itself.
>>>>
>>> Are you talking about RaaA or the UI simulator? IMO, the ideal UI
>>> simulator would be a close simulation of the target. I know that
>>> isn't always true now, but that is the direction the UI sim has always
>>> been moving.
>>>
>> It's not only not true, it's impossible too. We can maybe move it closer
>> but it'll never be close. Use qemu if you want to do that. Either way,
>> and as above, I don't see how target-tree'ifying would prevent anything.
>>
>>
>>>
>>>
>>>>> Similarly, the LCD code for the sim presents the main LCD, the
>>>>> remote LCD (if present on the target), a backdrop image, simulation
>>>>> of backlights, simulation of charcell etc. For RaaA, none of those
>>>>> complications are needed, but different complications may be - such
>>>>> as possible window resizing, or run-time detection of LCD size (if
>>>>> we go all the way with RaaA), or other things we haven't thought of
>>>>> yet.
>>>>>
>>>> I don't see any problem here. These complications won't touch the SDL
>>>> app, because it will not define SIMULATOR.
>>>>
>>> I don't understand your answer. My suggestion is that the
>>> LCD-simulating SDL code for the sim will be very different to the SDL
>>> code needed for RaaA, so it shouldn't be assumed that unifying it is a
>>> good idea - just because they are both using SDL.
>>>
>> But it isn't different. It's not like SDL offers you an incredibly
>> versatile API, it is very simple in fact. Even with SDL you're limited
>> to very few ways of doing it. There's no different way of doing it
>> differently *within* SDL happening. Other platforms may offer different
>> ways, but that's not an issue for SDL and not for the sim or the SDL-RaaA.
>>
>>
>>>
>>>>> Am I missing something obvious? Why is putting the sim code in
>>>>> target tree a good idea?
>>>>>
>>>> I think you mix up sim-specific code and sdl specific. The former
>>>> will stay specific for the simulator, the latter will be reused for
>>>> the sdl application because code duplication is bad.
>>>>
>>> Code duplication is not _always_ bad. My point with all this is that
>>> you may want to do things in fundamentally different ways in an
>>> SDL-based RaaA to the sim, and it's too early to say you won't.
>>>
>> It's not too early to claim that I think. I think I've looked into it
>> enough to confidently claim that things are not going to happen
>> fundamentally different.
>>
>>
>>>
>>>>> I would have preferred to have seen a new SDL target being added to
>>>>> the target tree, with none of the sim code in it - i.e. a shiny new
>>>>> SDL target without the baggage of the sim, and leaving the sim free
>>>>> to be developed and improved independently of RaaA (and in the
>>>>> opposite direction).
>>>>>
>>>>>
>>>>>
>>>> That doesn't make sense to me. The difference between the sims and an
>>>> SDL app boil down to the button and lcd handling. There need to be
>>>> very few #ifdef SIMULATOR to separate the SDL app from the sim.
>>>>
>>> That may be the case now, but I would argue that it won't be the case
>>> for very long.
>>>
>>> I would have wanted to keep an open mind about the possibility that
>>> the sim SDL code and RaaA SDL code would differ, and work on RaaA
>>> without worrying about the sim.
>>>
>>> If, much later during the development of RaaA, there is still a
>>> significant amount of the sim's SDL code left in RaaA, then that would
>>> be the time to consider merging the two, not now, before you've
>>> explored the possibilities.
>>>
>>>
>> Merging later is a much bigger pain that doing it from the beginning.
>>
>>
>>
>> If the RaaA app does something different than the sim later, then it
>> won't in the target tree area. It will be at higher levels. Remember
>> that the target tree only holds the *drivers*, it doesn't make up an app
>> on its own. And the drivers are specific to SDL, not specific to whether
>> it's an app or a sim.
>>
>> Best regads.
>>
> One thing stood out to me with the changes that have been made and
> Dave's concerns:
>
> The Rockbox libc implementation is not complete and it doesn't follow a
> large library like newlib or glibc. In the past I have run into bugs in
> the Rockbox libc functions. In those cases it was really helpful that
> the simulator compiled with the Rockbox variants rather than the host
> versions. It allowed for debugging the library calls on a level that
> would be difficult without a hardware debugger.
>

The opposite has also come up, that our implementations breaks host systems,
which is why we partly already used the host's libc.
The libc stuff hasn't changed over years now so I think it's unlikely
that we need
to debug it again. But even then, compiling specific files of our libc
functions is
easy enough (just change SOURCES) if we suspect a bug there.

The essential part was using the system's headers not the actual
functions. If we
keep the prototypes in sync we can always toggle back and forth between
the host's
and our libc implementations. And being able to do that helps us and
hardening our
implementations so that they remain correct.

> My thought on issues like this is that there should be some distinction
> between the simulator and RaaA if that distinction does not already
> exist.

It doesn't exist yet because there's actual code for RaaA yet. It's all
sim code
that received changes. But later, the sim will remain unchanged and continue
to work as it currently does and RaaA will become a real port.

> The question that should be asked before making a major change
> to the simulator architecture is: "Would the Rockbox way be helpful to
> debug issues on the target?". If the answer is "yes" then the
> infrastructure should be setup so that you use the Rockbox way for the
> simulator and the host way for RaaA.
>
> I think that looking at the simulator as just a UI simulator as Jonathan
> suggested is too narrow of a scope. It has value beyond that if the
> architecture is setup properly.
>

If you define UI as graphics, then it's too narrow. But if you define UI
as all
the more or less user visible code which also includes the playback or
buffering engine
etc, then it's quite accurate.

Best regards.
Received on 2010-05-16


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa