Compiling the RTEMS HEAD

[Ralf Corsepius]

On 01/28/2011 03:19 PM, Gedare Bloom wrote:
> On Fri, Jan 28, 2011 at 2:48 AM, Ralf Corsepius
> <ralf.corsepius at rtems.org>  wrote:
>> On 01/28/2011 07:43 AM, Chris Johns wrote:
>>>
>>> On 28/01/11 1:50 PM, Ralf Corsepius wrote:
>>>>
> <snip>
>>>> Well, the issue this thread has started with, is code fails to compile
>>>> on a platform it wasn't designed to used on and it being used for a
>>>> use-case it wasn't designed for.
>>>>
>>>> I.e. in my view, this question is 3-fold:
>>>> - Is this a legitimate design or a poorly designed case of code abuse?
>>>> In my personal opinion, the latter applies.
>>>> - the impact schedsim has on RTEMS code-base.
>>>> - the portability issues it suffers from.
>>>
>>> There must be no impact on the RTEM code-base in terms of design or coding
>>> levels.
>>
>> This code pokes deep into the RTEMS source tree ...
>>
> Does it poke or does it peek?
Peek would have been correct - I am not a native English speaker :)

> The code doesn't affect the source code
> of RTEMS, just the build process.
It will do, because keeping this stuff compilable will infect the rtems 
sources.

> Fixing the portability issues (and
> keeping it in the primary build) will help to detect problems during
> build tests,
No, it will gradually pollute the RTEMS source tree.

> so that bugs can be reported and fixed.  Since the target
> audience is RTEMS developers (not necessarily users), perhaps a
> configure option is the right choice here, somewhat like how the docs
> subdirectory is only built with the right flags.


>>> If the tool cannot use RTEMS code as is then it needs to change or the
>>> approach evolve to something else.
>>
>> IMO, the approach is flawed from it's lowest fundations upward. To me, it's
>> essentially a brute force attempt to revive what was once the posix/linux
>> BSP, but without the overhead and without proper integration (the
>> posix/linux BSP wasn't properly integrated either, but schedsim seems beyond
>> reason to me).
>>
> The difference (caveat; I never used the unix BSP) is that schedsim
> allows scripted testing of an RTEMS subsystem (scheduling).
The posix/linux BSP was a BSP which had allowed to run very basic rtems 
code on Linux and some other OSes and was implemented and integrated 
into the build process as separate cpu+bsp-pair. When looking to 
schedsim's code, those parts which are not peeked from the source tree, 
resemble very much to the former posix/linux BSP's specific code, I am 
inclined to believe this code was actually ripped from the posix/linux BSP.

Unfortunately the POSIX/linux implementation had sucked rocks, has never 
worked smoothly and was a nightmare to keep alive, and therefore had 
been abandon (IIRC, in rtems-4.10).

Nevertheless, IMO, it was still better than schedsim, which seems to be 
based on a "pure all code into a big bowl, stir and hope it 
builds"-approach.


>>>> The fundamental question to me however is: Is it worth it?
>>>> ... no user-base, no applications, questionable design, build-tree
>>>> bloat, ...?
>>>
>>> If we can attract research in real time schedule design then it could be.
>>> We cannot do this unless we provide something to help.
>>
>> But we can try avoiding wasting resources and time;)
>>
> The stated purpose is scheduler development:I personally haven't used
> the tool for this purpose yet, but I think it may prove useful if/when
> SMP support arrives.

I don't that an RTEMS simulator would not be useful - But, as I wrote 
before, this approach to me is simply beyond reason (to stay polite).


Ralf