Syntax and structure of federated configuration folders etc.

[LasseRosenow]

I try to summarize the state after our initial discussion.

In general when we are in a federated context, our program might consist of various federates that might even run on various platforms such as zephyr or riot.

[LasseRosenow]

1. We need to generate configuration folders for each federate (based on their platform)

Since the name of a federate is inferred from the LF file, it might be reasonable to generate the configuration folders etc. from within the LFC.

Following structure is currently implemented for zephyr:

- fed1
  - zephyr-config-file
- fed2
  - riot makefile
- src 
  - HelloLF.lf
- src-gen
  - HelloLF
    - fed1
    - fed2

Alternative Idea I just had:

- fed1
  - src-gen
  - zephyr-config-file
- fed2
  - src-gen 
  - riot makefile
- src 
  - HelloLF.lf

[tanneberger]

I think I prefer the last option:

Reasons:

• You probably have for every topology you have different configuration.
• No mixture of potentially only semi related subprojects.

[erlingrj]

Thanks for writing this up. BTW, the current implementation in Zephyr looks like you "Alternative Idea I just had", both federates gets its own src-gen folder. (Unfortunately, they both get src-gen for all federates, not just itself).

I am not sure I understand your point Tassilo. I think a common use-case, which Edward hints to looks like:

- src
  - MyApp.lf
  - MyAppConfig2.lf
  - MyAppDebug.lf
  - MyAppConfig3.lf

The different LF files will have a different main reactor, but probably have the same federates, only configured differently, e.g. turn on/off debug logging, or increase/decrease timer periods, algorithms to use etc. I don't think it makes sense to create a new "project" with a main.lf for each one of them, and instead I think option 2 is better.

[LasseRosenow]

Oups :D I think given that information I also tend to prefer number 2

[erlingrj]

So if you call lfc --generate-federate-templates src/HelloLF.lf or something, then it would code-generate one of those alternatives. And we would call make all from the RIOT projects, or west build from the Zephyr projects, or cmake -Bbuild && cmake --build build from POSIX projects. These commands would result in invoking lfc src/HelloLF.lf but putting the src-gen folder within the project folder (by using the -o parameter to lfc). And then call the respective build tools.

We could make it more efficient by implementing a command line option to LFC and ask it to code-generate for a specific federate. E.g. lfc -f my_federate_2 (this would only generate for the second federate in a bank called my_federate. This would be an optimization though.

[LasseRosenow]

It is a little bit odd because of the 2 different ways to involve lfc, but it is somewhat the reasonable compromise I think

[LasseRosenow]

2. We need a way to specify which federate uses wich platform:

Specify the platform per federate in LF using the @-syntax.

federated reactor {
  @platform(RIOT)
  fed1 = new MyFederate()

  @platform(Zephyr)
  fed2 = new MyFederate()
}

If the platform is not defined per federate, we might want to fall back to the default platform of the file

target uC {
  platform: RIOT,
  timeout: 1sec
}

federated reactor {
  fed1 = new MyFederate()
  fed2 = new MyFederate()
}

[tanneberger]

I think we really should go for the @type::feature() syntax otherwise we will have a big zoo of annotations.

I would like to see:

federated reactor {
  @federate::platform(riot)
  fed1 = new MyFederate()

  @federate::platform(zephyr)
  fed2 = new MyFederate()
}

[LasseRosenow]

One might argue, that federate is redundant in this case, as this whole data is within the federated reactor block.

But in general I agree, that something like @interface::coap(config) seems reasonable.

[erlingrj]

I would argue that it is mainly an aesthetic concern, which is also important, and I agree that it looks nicer. Although, one might ask, why shouldn't it be federate::interface::coap(config), since it applies to a federate.

[LasseRosenow]

My point would be to not write federare because it is redundant information :)

But I can also see the point that maybe auto complete etc. Might be easier with clear and full namespaces there