[riot-devel] [Configurations Task Force] First draft

Jose jose.alamos at haw-hamburg.de
Thu Sep 27 17:46:22 CEST 2018


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/
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20180927/aaa8aaca/attachment.html>


More information about the devel mailing list