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

[Jeremy Rosen <jeremy.rosen@xxxxxxxxxxx>]

quick remark : you seem to add too much files to misc/release-file more specifically all the generated files from your example should probably not be comitted to svn

more generally, with this patch we have three policies

* flush at end of major time frame

real time calculation are easy : we consume a fixed amount of time at the end of every MTF for the time needed to flush all possible ports

* flush at end of partition slot (only for the exiting partition, but that makes sense)

again, calculation are easy, we add to each window a time corresponding to the time needed to flush all ports the corresponding partition can write to

* flush at the first end of window after a period of X

That last one suprises me a little, do we have a use-case for it ? the timing calculations to know exactly when the flush will take place seem non-trivial to me, i am probably missing something here...


I will probably add a "flush immediately" policy too once this patch is commited. Again the calculations should be trivial since the time needed to flush is assigned to the call to the sending function itseelf


As far as commiting goes, i'll let Julien speak up. Do you have commit rights on tuxfamily ?

    Cordialement

    Jérémy Rosen

fight key loggers : write some perl using vim

----- Mail original -----
> Dear pok user and contributors,
> We tried to take into account remarks and suggestion made following
> our proposal few weeks ago.
>
> We propose three examples to illustrate the flushing policies we'd
> like to integrate
> to pok for inter partitions communications.
>
> The example folders are arinc653-sampling§flush-X, X being mif, maf,
> windows.
> README files describe the expected behaviors.
>
> We also provide the commented sched.c file implementing the
> behaviors.
> We executed make commit, everything went well until the execution of
> the commit command (that cannot complete as expected without being
> registered).
>
> Thus, what is the next step ? You would find attached the svn diff of
> our working copy with respect to the latest commit including
> examples, Makefiles and so on.
> Wainting for comments and suggestions,
> Best regards Thomas
>
> ps: I have been obliged to modify by hand the release-files file to
> obtain correct release archives. Otherwise, example files were
> missing. Did I get it right or is there another way to update this
> file ?
>
>
>
>
> ----- Mail original -----
> De: "Jeremy Rosen" <jeremy.rosen@xxxxxxxxxxx>
> À: pok-devel@xxxxxxxxxxxxxxxxxxx
> Envoyé: Mardi 29 Janvier 2013 16:08:30
> Objet: Re: [pok-devel] Proposing a patch to sched.c
>
> I had a similar need and developed a patch of my own, but it wasn't
> in a commitable state yet, just for testing so far...
>
> my approch was a bit different (the flush happened per-port at write
> time) but your patch would fullfill my need too...
>
>
> I'm looking forward to seeing this commited...
>
>     Cordialement
>
>     Jérémy Rosen
>
> fight key loggers : write some perl using vim
>
> ----- Mail original -----
> > Dear POK users and contributors,
> > We propose to integrate the following functionality in POK
> > concerning
> > inter-partition communications.
> > The purpose is to propose alternatives to the default flushing
> > policy. This proposal is the outcome of a joint
> > work in our research group with Etienne Borde and Laurent Pautet.
> >
> > 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.
> >
> > We propose the following code to handle these two additional
> > semantics and handle their selection. The code is still compatible
> > with ocarina (the default policy is still the one used before).
> >
> > Even if we do not propose to update ocarina to handle pre processor
> > macro definition to activate them, we
> > take advantage of this proposal to inform you that we are
> > developing
> > an Eclipse plug-in integrated with the OSATE  framework to handle
> > pok code generation. If you are interested we can provide you
> > access
> > to the current state of the project.
> >
> > More detail on the patch :
> > Files affected : sched.c
> > Optional : new example directory with model integrating properties
> > used in our code generation framework to activate the different
> > policies.
> >
> > You can find attached the diff of the affected file with the latest
> > revision of POK (#44).
> >
> > Pol1 is activated when the following macro is defined :
> > POK_FLUSH_PERIOD
> > You need to bind it to a value dividing Major Frame duration
> > (should
> > be checked / enforced at code generation time)
> >
> > Pol2 will be activated when the following macro is defined :
> > POK_NEEDS_FLUSH_ON_WINDOWS
> > No particular value is required
> >
> > 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.
> >
> > Best regards,
> > Thomas ROBERT
> > -------------------
> > Lecturer,
> > Telecom ParisTech - Département INFRES
> > 46 rue Barrault, 75634 Paris Cedex 13
> > France.
> > -------------------
> > tel : (+33) (0) 145817749
> > -------------------
> >
> >
>
>
>