Re: [pok-devel] Proposing a patch to sched.c

[ Thread Index | Date Index | More lists.tuxfamily.org/pok-devel Archives ]


Dear all,

Le 27/01/13 20:04, Julien Delange a écrit :
On the other hand, having some tests would be worth. On the other
hand, the tests relies on your code generator that is not supported by
the POK testsuite. Several solution could overcome this issue:
- Use your code generator in POK testsuite and replace Ocarina with
it. It assumes that you tool is able to generate all the code that
Ocarina can already handle
- Integrate your tool in addition to Ocarina for some examples. So,
some examples will use Ocarina while others use your code generator
- Just integrate the generated code "as it" without changing the
testsuite. It was done for some example. In that case, Ocarina is not
invoked, the example for the kernel and the partition is in the
repository.

About option 1: our code generator does not cover yet all the examples treated by Ocarina. In particular we do not deal with the health monitoring part.

About option 2: we already have tests for the patch proposed by Thomas, which means 3 AADL models with new properties and the corresponding generated code. All our tests are available there: https://circe.enst.fr/hudson/job/RAMSES-Test/ws/ramses_test/test/ . Those that illustrate the patch are arinc653-sampling-flush-mif, arinc653-sampling-flush-maf and arinc653-sampling-flush-window. These tests are executed every night using the current revision of the pok repository (plus our patch in this case).

As a conclusion: option 2 is already implemented even though not directly within the POK toolsuite. I think an update of Ocarina will be very simple in this case (a one-to-one mapping from AADL model to a C macro in the generated code).

But the question would raise for any contribution to POK that is not directly implemented in Ocarina... For this part it is up to you guys to define the rules.

Etienne.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/