Compiling the RTEMS HEAD

[Gedare Bloom]

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? The code doesn't affect the source code
of RTEMS, just the build process. Fixing the portability issues (and
keeping it in the primary build) will help to detect problems during
build tests, 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
approach is generally applicable, one could define for example a host
simulator for other RTEMS subsystems, and enables isolating the
subsystem for testing.  Including the tool in the build/regression
tests could provide a way to do unit testing.

The only real questions are:
  1) Is the design right/wrong? If wrong, how so and what steps to fix?
  2) How to improve portability?
  3) How useful is the tool?

>
>>>> What if we only built it if enabled and the host compiler supports the
>>>> RTEMS C standard it currently supports ?
>>>
>>> Well, checking for "standards" doesn't work (Whose standard? Which
>>> standard? Whose interpretation of a standard?). The classic autoconf
>>> approach (Check for features, try to gracefully degrade if possible and
>>> bomb out it not) could be made workable, however.
>>
>> I was thinking about some simple tests and if they fail to not build. For
>> example gnu99.
>
> Well, the problem with this is: What to test for and how?
>
> I mean, we can try to check for "is the compiler GCC and accepts --std=gnu99
> then set CC_FOR_HOST=gcc --std=gnu99", and "bomb out" otherwise.
> This will help in many occasions, but in others it won't, because each gcc
> release and each vendor-gcc has a different understanding/interpretation of
> --std=gnu99.
>
> In other words, --std=gnu99 would be an initial step to hide away most
> breakdowns from users (Setting CC_FOR_HOST="gcc --std=gnu99", schedsim
> compiles under CentOS5.), but there is much more to do (As anybody tried to
> build schedsim on MacOSX, Solaris, MinGW or Cygwin using their native,
> vendor-supplied compilers or icc on Linux?)
>
>>
>>> 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.  Creating a way to test code with more control
than full emulation (i.e. run RTEMS test cases on a simulator) seems
useful.  Having the simulator build in conjunction with RTEMS makes it
an accessible, viable option to test core changes, instead of having
to hand-write new testsuite applications.

Ironing out the bumps might also allow integration with other RTEMS
automatic testing. It could also lower the barrier to entry for RTEMS
kernel development.  Finally, if the design is good, simulators for
other subsystems might prove useful.

-Gedare

> Ralf
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>