Minutes from face to face meeting @ FU Berlin on February 04, 2014

Minutes from the Face-to-Face Developer Meeting @ FU Berlin on February 04, 2014

• Local participants: Lotte, Emmanuel, Christian, Martine, Thomas Eichinger, Ludwig, Hauke, Oleg
• Skype participants: Thomas Watteyne, Mic Musk
• Minute taker: Lotte
• IRC scriber: Emmanuel

Agenda

• OpenWSN: Status and Outlook
• current state of the implementation
• next steps and towards the IETF plugtest
• strategy for joint development and optimized integration
• Features for the Next Release (aimed for end of March)
• documentation and cleanup
  • Doxygen documentation in (at least) all public headers
  • License headers for all c files
  • CI up and running and verifying this process
  • platform support table
• new driver model
  • Hauke will give a short presentation: http://riot-os.org/files/Driverlayer.pdf
• porting guide and platform interface, particular for the STM32
• network stack fixes gathered from the upcoming plugtests
• optional: new concept for forwarding table
• optional: improved RPL structure and non-storing mode, AODVv2 and OLSRv2
• optional: pthreads
• Makefile structure
• how to set the include paths
• include dependency information in Makefile.include (instead of Makefile.dep) -> Makefile guard required to avoid loops
• module naming scheme (e.g. sys_crypto_sha256)
• Open discussion

RIOT developer meeting minutes [04.02.2013]

OpenWSN: Status and Outlook

current state of the implementation

Thomas (local):

• right now, it runs inside the RIOT threading model with own thread & event loop
• started developing for the TelosB board
• removing hardware dependencies from the OpenWSN part
• removed bsptimer
• next step: integrate RIOT radio driver & radio timer (which RIOT doesn't implement yet)
• Question: to which extent/abstraction layer do we want to integrate OpenWSN?
• aiming to run it on iot_lab-M3 board for plugtest in London
• interesting idea: exchange vtimer & opentimer

Oleg: vtimer is not fitting the requirements
Thomas (local): yes, it is, because opentimers have a similar purpose as vtimers

next steps and towards the IETF plugtest

Thomas (remote):

• agrees with Thomas (local) on the timers, two types are perfectly aligned with the ones from OpenWSN
• OpenWSNs scheduler is not optimal; having scheduler & timers from RIOT will be interesting
• looking forward to the plugtest in London

strategy for joint development and optimized integration

Thomas (remote):

• once the RIOT scheduler is in place: porting to (10) platforms & rearranging, will take some time
• RE radio driver integration: warning about the strangeness of the way they handle RIOT radio drivers: when you transmit, you first load the packet into the radio & then tell the packet to transmit

Features for the Next Release

documentation and cleanup

• CI up and running and verifying this process
• platform support table

what we need

• license cleanups
• public header documentation!
• table which feature is supported on which platform (Hauke started table in the wiki already); could be extended to issues etc
• Oleg: does it make sense to have a responsible maintainer for each platform? (which can be appointed the issues for this platform & nows who is able & willing to fix this)
• Everyone agrees. TODO: state maintainers on aforementioned wiki page

new driver model

• Hauke gave a short presentation: http://riot-os.org/files/Driverlayer.pdf

• code is in the pull requests

• Mic Musk comment: increasing the footprint size is problematic. how do we keep the balance between features & minimal memory footprint

• Hauke: Scaling for portability is very important for RIOT. We're conscious of that and tried to keep the footprint additions as minimal as possible

• Oleg: can you state the added overhead in your pull request?

• Hauke: yes. ROM depends on hardware, but RAM: of course

porting guide and platform interface, particular for the STM32

• towards a more professional porting & debugging workflow
• all the old drivers will continue to work, it's just an add-on for the future
• stm stdlib implementation is not usable because of license issues; idea: use startup files of libopencm3; include them as an external package like we did with libcoap
  note: I fear I didn't know enough to follow this conversation properly, so it'd be great if someone with more background knowledge could smooth this out.
• still needs work

network stack fixes gathered from the upcoming plugtests

optional: new concept for forwarding table

• ongoing discussion: where to put the forwarding table (separate it from the routing protocols)

optional: improved RPL structure and non-storing mode, AODVv2 and OLSRv2

• rpl nonstoring mode implemented right now
• aodv and olsr also in the making
• might be added to next release

optional: pthreads

Makefile structure

• needs to be cleaned up to be more tree-like

how to set the include paths

include dependency information in Makefile.include (instead of Makefile.dep) -> Makefile guard required to avoid loops

• idea: every module has a makefile.include
• at some point you'll have to include this
• every makefile modifies include paths
• Makefile.dep should go into Makefile.include
• sounds like a clean solution

module naming scheme (e.g. sys_crypto_sha256)

Open discussion

• Mic Musk: what's the positioning of RIOT? What is RIOT going to be like?
• Emmanuel: there are characteristics that make it interesting, but they're kind of generic. We've started to build things on top of the microkernel that go into different directions. So starting from the kernel, there are various possibilities. It remains to be seen what people do with the modules and also the kernel. People were talking about using RIOT for virtualization to replace hypervisors & such, which is a very unusual approach. tl;dr: pretty diverse, but they all have the microkernel in common. What direction do you see or what are you interested in?
• Mic Musk: I'm researching robotics & WSN, have been doing that for years. My startup (CrabxLab) is building communication devices for the IoT. We're interested in developing really low-power nodes which will only do machine-to machine communication for real-world applications and I see RIOT as promising for us to use in the near future. But it might not be ready for a commercial product yet
• Hauke: that's still aligned with the way we thin about RIOT. of course we have the academic approach, using it as an experimenting system (requirements: open, flexible, not so much stable). New Target: hobbyists. We talked about commercialization and the next release is a step towards stability.
• Ludwig: most of the RIOT developers feel this is a true Open Source project, that it wants to be a community project
• Oleg: we aim to bring a proper OS to places where you can't (or don't want to) squeeze in Linux
• Mic Musk RIOT is lacking methodology and tests
• Emmanuel: we have a pretty strict methodology already, the FU has a real world testbed, you can test very quick & easy with the native port. The culture is involving in this direction
• Mic Musk suggestion: pick out 1 or two recommend platforms for the community so interested people can get started easily.
• Emmanuel: true, we took a long time to decide. Hoping to pick out one soon. Open to any suggestions
• Emmanuel: curious: Why are you not considering contiki?
• Mic Musk : the kernel and the scheduling will limit the processing capabilities of the entire system. we need something that can support real-time as well as powerful scheduling. right now, we're considering commercial systems as well, but we're interested in something brand new, that's why we're interested in RIOT
• Thomas (remote): does RIOT have any plans to implement security systems?
• Emmanuel: There is an ongoing implementation of dtls, but the guy who's doing that is not very responsive
• Thomas (remote): I've got an army of undergrads that need projects and security problems are very fun, so I just wanted to know what the status is for the next meeting with them