| Re: [pok-devel] Proposing a patch to sched.c |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/pok-devel Archives
]
- To: pok-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [pok-devel] Proposing a patch to sched.c
- From: Julien Delange <julien@xxxxxxxxx>
- Date: Sun, 27 Jan 2013 14:04:48 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=XH7k5HGXuNhlpiSInEaRsyI0dMP465/2sDfimyZzUkU=; b=Rv6GIRu3KsnNnAGXhD1Emcdc7fT0HkNBM/Fe95FNs0gH0mgfZYgBQo+28+cI4iOnPu V5vowOv6R9h4VhpXc9fGyU4WxIFD6DICBH8zsdNGPuntl1LnAEMOxD+64qCmEMkcvqGp FiAkc0bJk3tAuqFYtJqFQRl0m9LDmUNl1VdB4QI8t1a57elcrjlX6AZ8iMtS0dYsQHZf PrZo/xWtlaLCe/lkuomE/xmWZNzeINQIMB9WOTofVetZ6wujQdPfuCYdXZemlbjrzUnQ YAa0VZ4mKaRp0244XrkHHYdInojzZwELgDB8GGHGgSoqItQYfDAKAJjeEyaS5SAlmME1 JN1w==
On Fri, Jan 25, 2013 at 1:58 PM, Thomas Robert
<thomas.robert@xxxxxxxxxxxxxxxxxxxx> wrote:
> Up to now the flushing policy cannot be configured and consist in a periodic flush at each Major Frame beginning.
> In industry two other configurations are often considered:
> Pol1: Periodic flush with a period dividing the Major Frame.
> Pol2: Systematic flush of partition outgoing ports when leaving its scheduling slot.
Fair enough, it makes sense for me. Please integrate these changes.
Also, may I suggest that some documentation is added about that (for
example on the wiki) ?
In fact, I think by having all these different contributions, it
enhances POK and makes it more compliant for industrial use. It would
also gives arguments for using it on different projects having timing
requirements on communication.
> If none are defined the default behavior is enforced.
> We 'd like to know your point of view about integrating these functionalities, as is or with limited modifications, in POK trunk.
On one hand, I think what you suggests make sense, especially because
the changes are motivated by requirements you experience during
several projects.
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.
Solution 1 & 2 are the most complicated and require to update the
testsuite, which might be painful. Solution 3 integrates generated
code so that you do not need to update the testsuite at all and it
does not need any integration on your side. But at least, would add
some code that test your new feature.
Anyway, I am very pleased to see that new features are being developed
and that some people give back to the community. Having other
contribution coming from other research projects would be appreciated
:D