Proposal: Allow setting the stack size on build time

[torfmaster]

Contents

In this PR I propose a way to set the stack size on build time. I use a very simple replacement routine on build time to create the layout files of the app which sets the stack size obtained from the environment variable APP_STACK_SIZE.

Advantages

I think there will be more use cases which need to change the layout file on compile time as for example multiple app support.

Disadvantages

Changing the stack size is not possible per app, at least not trivially. If this is absolutely required one could read the required stack sizes from configuration files next to the examples. However, the main use case for the build system should be supporting to build one app in one crate depending on libtock-rs.

Also reading from environmental variables might not be the preferred way to configure a build system. But any change to this should come alongside with a change to the usage of the variablesPLATFORM, APP_HEAP and KERNEL_HEAP.

Extensions

As build.rs is growing some of the functionality should be moved to a separate "build tools" crate.
Moreover, I feel that some sections of layout_generic.ld and the layout files themselves could be generated from primitive values like the beginning of the ram, the size of the kernel from the platform etc. so the linker files get easier to maintain.

[alistair23]

This doesn't really get us anything does it? The default stack size is too large for the HiFive1 so now an entire board won't work without users specifying an environment variable.

[torfmaster]

This doesn't really get us anything does it? The default stack size is too large for the HiFive1 so now an entire board won't work without users specifying an environment variable.

As you said: a user of the library can set the stack size of the board. I could put the smaller stack size into the Makefiles making it more obvious.

[Woyten]

I would propose to define an overrideable default stack size per board. The stack should be big enough s.t. the largest possible number of examples runs without problems. This is very important for new libtock-rs users to have a good starting experience. More experienced users will start to have a look at the build files / documentation and learn how to configure the stack for their needs.

The opposite approach based on defining a stack size per app is conceptually wrong in my opinion as the stack consumption does not only depend on the app code but on the target architecture and other compiler settings as well.

[alistair23]

The stack usage is mostly app dependent. It is also compiler and architecture dependent, but I don't think there is much difference between the architectures for stack usage.

[torfmaster]

@alistair23: would it make sense to merge this PR in your eyes? As a next step we could move the examples which work with the Hifive board into separate crates (although I won't promise that this will be a trivial task as we have never tested using libtock-rs as a dependency).

[alistair23]

I'm not sure what the advantage is here, now it seems like users have to figure out stack sizes and change them manually.

[torfmaster]

I'm not sure what the advantage is here, now it seems like users have to figure out stack sizes and change them manually.

That point is that

• users can set the stack sizes at all (and can do it similarly as for the heap sizes)
• we can move out examples with "special requirements" for the stack sizes to external crates and change the stack sizes only for this examples (in upcoming PRs)
• this in particular enables small examples for hifive

I suppose this is what you wanted to achieve with #180 ?

[alistair23]

This seems like a step in the wrong direction though.

• Users can set stack sizes, but I don't think that is something we should ask them to do
• Now we can't event set a smaller stack size for more resource constrained boards

[torfmaster]

I personally don't need this change I rather looked for a straightforward way to implement the changes aimed in #180 which I refused to accept.

Users can set stack sizes, but I don't think that is something we should ask them to do

Requirements for heap/stack are different for apps which use libtock-rs but are outside of the repository. There should be a way to increase the stack size, an environment variable is such a way. In an ideal world, static analysis would compute the maximum stack size of a (non-recursive) app and set this value, however, this is out of scope.

Now we can't event set a smaller stack size for more resource constrained boards

You can. You can even hard-code this is in the Makefile.

I am okay with closing this PR alongside with #180

[jrvanwhy]

Closing because I believe #244 made this obsolete.