Dear RIOT developers,
As discussed during the RIOT summit, here is a first draft and
workaround for a possible configuration mechanism [1].
All comments and feedback from the community will be really helpful!
Best regards,
José
[1]: https://github.com/RIOT-OS/RIOT/pull/10058
On 8/29/18 4:01 PM, Jose wrote:
Here is the issue [1].
Best.
José
[1]: https://github.com/RIOT-OS/RIOT/issues/9856
On 08/29/2018 11:58 AM, Jose wrote:
Hi all,
I've seen some discussions [1] about configurations in GH Issues. It
seems there's interest in the community about exposing these kind of
discussions in the devel mailing list, so I suggest to keep them there.
I will open an issue for tracking the status of the Configurations
Task Force, so it's easier to reference from Github.
Cheers!
José
[1]: https://github.com/RIOT-OS/RIOT/issues/9825
On 08/14/2018 05:54 PM, Jose wrote:
Hello all,
Since the 2018.07 Release is over, I'm back again because of the
interest in "Kernel and Application specific configuration" TF
proposed a month ago [1].
This is a quite big topic and probably has different scopes, so
before organizing a meeting would be nice to get in sync and know
the motivation of everybody and what kind of problems should be
addressed.
I start with my motivations:
/1) To have a mechanism to configure different RIOT components
with key-values (core, network stacks, user modules,
applications, etc)/.
Some examples out of my head:
- Private keys, user delays, and all application specific data.
- Network related configuration (NIB table size, default
channels, prefix, etc)
- Debug by module or group of modules (e.g DEBUG=1 in GNRC
should enable debug in all GNRC modules, but debug enabled
in gnrc_udp only should affect that module)
IMO it's a plus if the mechanism allows a user friendly mode
(NCurses like interface) and config files for advance users or
scripts that generate firmwares.
2) /To have a friendly mechanism for describing boards (arch,
cpu, mcu), board specific configuration and relevant metadata. /
Zephyr, for instance, uses configuration files for describing
boards [2]. That makes easy to describe a board in case of end
products (e.g boards that are not located under `boards` dir and
probably don't have a board shape [3]) and handles the problem
where the same board has several revisions or very similar models.
I encourage you to also write about your motivations and problems to
be addressed, and see how we continue.
Best regards,
José
PS: I will create the Task Force entry during the week.
[1]: https://lists.riot-os.org/pipermail/devel/2018-July/005825.html
[2]: http://docs.zephyrproject.org/porting/board_porting.html
[3]:
https://www.ikea.com/gb/en/products/lighting/smart-lighting/wireless-led-bulbs/
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
