Notes: Virtual Maintainer Assembly (VMA) 2024.11

Community
,
1

2024.11 VMA

Attendees

  • Koen
  • chrysn
  • maribu
  • mikolai
  • Oleg
  • benpicco
  • fabian18
  • Teufelchen
  • karl
  • Kaspar
  • martine
  • emmanuel
  • dylad

Agenda

  • Agenda Bashing - 5’ (chrysn)

  • 2024.10 Release debrief from Release Manager - 5’ (benpicco)

  • Outlook on upcoming 2025.01 Release - 5’ (Kevin)

  • Upcoming release managers and VMA moderators - 5’ (chrysn)

  • Revisiting “Standard C” in our code style - 30’ (mikolai, chrysn, maribu)

  • Moving FIDO out of RIOT - 5’ (maribu)

  • GA follow-up: RIOT-rs changed its name to Ariel OS; approaching first release. - 10’ (Kaspar, chrysn)

  • AOB

Notes

Agenda bashing

  • new item from maribu: Moving FIDO out of RIOT

2024.10 release


Ben: bit delayed, just missing release notes – if all fine, release today.
Ben: Some automated tests are not executed any more.
Ben: about release specs; not sure what should run automatically.
Teufelchen: …
mikolai: List here reminds me of issues during my release.


chrysn: What do?
Teufelchen: Delete tests nobody ever runs?
Martine: One being fragmentation of fragmentation? (IP and 6lo layer)
ben: Can test on native.
Martine: Was troublesome on multihop.
Kaspar: Only tests failing, not the underlying impl?
Martine: Would have needed a proper MAC layer. Now we have one.
chrysn: 3 of you propose change?
Martine: next release; experimental/skip for now.


mikolai: In each folder in specs there is a test_spec.py, that says for which tasks there are tests.
Martine: Checkmarks should show that too. (Murdock reports failures)
mikolai: Could improve README to show that.

2025.01 release outlook?

(skipped)

Next roles

  • 2025.01 at Kevin

  • 2025.04 RM: mikolai volunteers.

  • 2025.02 VMA: martine.

Revisiting “Standard C” in our code style - 30’ (mikolai, chrysn, maribu)

Starting statements:

  • “Can we have #pragma once?” (weekly)

  • “Can we have #include_next?” (for stdio_null)

    • we are already using #include_next throughout the code

  • “Is this all moot because de facto we are already very much not standards compliant?”

  • “Should the code convention reflect an unachieved aspiration, a blanket statement that whatever clang and gcc can do is fine, or a concrete set of implementation defined behaviors we require, or does this differ by whether code is platform dependent?” (That list might contain that type punning behaves as expected given the endianness, that packed works (used in GRNC), attribute(weak), and any linker section trickery)

  • “Is it enough if for every non-std thing we use for convenience there is a cocinelle script that dumbs it down?” (Eg. for pragma once and sized arguments)

  • “Don’t forget third-party tooling. E.g., c2rust is C99 only. Every used language extension reduces compatibility. Be reasonable. The benefit of #pragma once vs. include guards might not be worth the loss of tools.”


Martine: Had example about space code compilers, but not sure how realistic.
Karl: sdcc is an interesting compiler; #pragma_once is supported, just was not documented previously (now is).
Oleg: Have been advocating for this 10+ years; surprised we haven’t added exception for #pragma once. Remember in previous job, had customer who liked MISRA C, and even there we had exceptions like pragma once. There are definitely exceptions that can be made b/c it’s just academic/theoretical thing. Would be really surprised finding RIOT support for compiler w/o prama once. Not sure about include next. Personally would .


Kaspar: For 3 lines → 1 line, we change all our code? Header guards work, are CI checked.
Karl: Can just not reject new code for pragma once. It’ll slowly work its way in.
benpicco: Inconsistency is worse than header guards. Don’t care about pragma once.
Martine: +1
chrysn: +1
Koen: Are these a real proposal or just part of discussing non-std C?
Mikolai: pragma once came from inconsistency around Doxygen style, trying to move them; main part is include_next.


Kaspar: Are there no alternatives to something?
chrysn: GCC says there is no alternative
benpicco: It’s in some archs
Martine: That’s platoform specific.
maribu: Also fortify_c headers.
benpicco: In stdio it saves space b/c it removes the formatting code.


chrysn: So, starts shaping criteria – take to CODE_STANDARDS?.
maribu: Currently says “std C only”, which is not the case.
maribu: We have __attribute__((packed)) in non-optional code paths.
karl: Comment above on c2rust being C99. Use that as common compatibility layer (??)? Probably relevant to ther tools than c2rust. And then be less strict on other parts.
chrysn: c2rust already only works on headers only.
maribu: static inline is just a hack. LTO would be so much better.
karl: extern inline would do that just as well.
maribu: Either way, compiler with LTO is in a better position to decide.
Teufelchen: For me, difference is mental load. If compiler can do something (even with a bit less performance!) and every dev gets benefit and not just those who decide carefully, it’s good.
chrysn: There’s one more case for c2rust needed, not just static inline, also preprocessor construction, but reducing it to that would be fine already.
maribu: Let’s get rid of those too.
karl: Does c2rust do pragma once?
chrysn: Unsure, but also unsure we even have consensus on that.


chrysn: Back to general topic.
Kaspar: Is there a standard that is relaxed that we can reference? gnu11?
maribu: No, eg. declaration of parameters in function with a semicolon, so that size_t len, char buf[len].
Kaspar: Clear rule is preferable to individually discussed exceptions. “Everything that compiles on CI” is also a rule.
chrysn: Unaware of any spec that says “pragma once is OK”, and “byte has 8 bit”.
maribu: POSIX says 8-bit byte.
Karl: For exotic compilers, could let GCC do preprocessing.
chrysn: Requires GCC preprocessor to know precise include path of compiler; that might be doable.
Kaspar: We did rules b/c we thought it’d ease maintenance. Using one preprocessor and another compiler is not making things easier.
maribu: Also, what helps having code quality?


maribu: I think there is an agreement that we want include_next, and no agreement around pragma once.
maribu: And to allow attributes: used, force_inline, packed, and unused.
maribu: And any attributes in CPU code that make sense for platform.
Oleg: So any crazy attributes go into CPU :slight_smile:


Karl: pragma_once solves issue of _H collisions.
chrysn: Do we run into that?
benpicco: I did with stdio_null, but that’s just our convention, we could alter that convention.


Martine: Back to packed. It’s throughout all the network code.
benpicco: And in registers.


Kaspar: Why doesn’t compiler complain that std11 is used with packed?
maribu: __attribute__ tells compiler to not give a shit.
benpicco: We added __attribute__ when we had pedantic enabled, might remove this wrapper.


chrysn: So, PR to augment coding convention upcoming. Treat CODING_CONVENTION like core with >1ACK?
Kaspar: 2 ACKs.
Oleg: …?
Kaspar: Maybe add note to use it sparringly, b/c we may want to roll back.
chrysn: packed is definitely not used sparringy.
Kaspar: Let’s not do huge rewrites just for that.
Martine: If there are examples of where there is no good reason, we can still look at those concretely.
maribu: Best counterexample are network byte order types. Sometimes also used outside network code. Viewing the type in debugger is 3 screens long.


maribu will start PR to change coding conventions.


AOB on this?
maribu: Assumptions that some kinds of pointers are always the same size. (Like, casting data pointers cast to each other w/o going through void pointer). This is even the case for the “crazy” ones.
chrysn: so PR to say “we allow this but encoruage going throug void* as is proper”? (sounds like yes) especially around casting f(*foo) to f(*void). Should not need to care about that distinction.

Moving FIDO out of RIOT

See discussion in forum: Moving FIDO2 implementation out of RIOT


maribu: Should not have been merged; would require maintenance to get to useful state. Based on RIOT C it would not make sense to use FIDO outside of experimental code. Would be better to get rid of it.
Karl: If this is about security aspects, there are pushes to add security coprocessing. Could we have a repository where applications like this are put?
Martine: Used to have application repo, running out of date all the time, b/c release manager always forgot to update; same for app repos, same for tutorials. Don’t see how this would get better. Thus against having things outside. If it’s about throwing FIDO out, that’s another discussion.
Oleg: Agree w/ Martine; on forum discussion: Not many people involved. No personal opinion.
maribu: We believe nobody actually uses this. Forum post shows one user (who might just as well maintain it on own repo, as anyone else does).
Oleg: Same for many example apps.
maribu: Examples are helpful for other stuff. FIDO is special-purpose.
benpicco: Good about FIDO is author cares. Agree from looking at code makes it undesirable to deal with it.
Kaspar: Is this library or end user app?
Karl: Module, tests, examples.
benpicco: Like the idea of having the functionality, but not confident in its state or maintenance (questionable storing in flash etc). Big thing, would need lot of guidance to get it right. Author is very involved, own repo might work better.
Martine: For context, Nils was master student at FU.
Kaspar: Code has glaring bad quality so you’d also move it out? And is “security” code? Is that the concern? That’d be grounds enough.
maribu: Yes. It’s a master thesis “dumped” into the repo.
Kaspar: Happens. Usually removed, most times students leave again anyway.
Teufelchen: is the author still employed?
Martine: Don’t think so.
benpicco: There are open PRs, but nobody wants to review b/c of general quality.


chrysn: Asked Nils to move it to out-of-tree?
maribu: Didn’t ask, more about getting it out of tree.
Karl: Merged thigns where they improved stuff. Problem is “what are we signalling by removing?”. It does all the things we ask people to do.
maribu: Didn’t INRIA people start with this code?
emmanuel: Haven’t heard back from them. Haven’t been interacting on Github/Forum etc. Wouldn’t base our decision on this.
Kaspar: Staging area?
Teufelchen: Sounds good. At least for next time this comes up. Kicking it out sounds rude. Maybe just tell author we’re not happy with state.
?: It’s marked as experimental.
maribu: Who would review enhancements? Nobody really reviews and wants to review this.
Teufelchen: Just never looked at it.
maribu: Ran with just a tad stricter flags, and they found many really obvious and trivial issues.
karl: Happens in many places.
maribu: But this is security code.


Teufelchen: Can approach Nils, collect issues, decide next VMA.
Kaspar: Would FIDO be in scope for RIOT?
Martine: Was never in discussion – yes it is in scope.
maribu: Think it’s not in scope b/c it’s application and not part of OS.
Martine: FIDO generally is something we should have. FIDO token maybe not (?).
chrysn: Wouldn’t use a RIOT based FIDO for my bank account or eIDAS, but fine with web logins, esp when forced to do 2FA.
Karl: So remain code quality issues. Approach author in friendly way.


Oleg: Agree w/ Karl, and Teufelchen’s proposal to approach him. Just requires reviewer and person to guide.
Kaspar: How about just everyone take 10min in the next few minutes? Then reconvene.
maribu: Normally this would have been a PR, nobody would have cared; someone accidentally merged it. (Merged by Peter, conflict of interest)


Martine: If there is no review (because mentor is blocked), things get very frustrating w/o other reviewer.
Teufelchen: Mentoring Review != Mentoring Merge!

Consensus: Ask to improve, revisit at next VMA.

GA follow-up: RIOT-rs → Ariel OS

See Ariel OS


Kaspar: RIOT-rs is now called Ariel OS. Coming along well, does useful stuff (shows blinky), release before Xmas.
Kaspar: PR to be merged that uses high-level Rust code shared between RIOT and Ariel. See feat: Share code with RIOT OS by chrysn · Pull Request #585 · ariel-os/ariel-os · GitHub
Kaspar: Looking forward at fruitful competitive coexistence, sharing code, summits and more.
Teufelchen: is Ariel OS aiming to implement traits/interfaces for UART etc (???)
chrysn: yes. This is part of what the perspective of sharing code
chrysn: we could go beyond going beyond sharing these interfaces


Oleg: How do we proceed community-wise? Is this common community? Weeklies probably don’t make sense to have joint, but eg. VMAs? Summits?
Kaspar: there is a big overlap (4/5 Ariel maintainers are long-term RIOT contribs). For summit, we’ll be there anyway; Ariel talks will be relevant b/c RIOT reference. Ariel has different technical stuff and decisions, but open meetings (but no benefit in merging all meetings).
Teufelchen: Have to rewrite URI parser soonish, will do in Rust. Ariel will need too. Parsers are out there but huge space; IoT space is narrower.
chrysn: Yes!
maribu: Strategic cynical: RIOT contributor graph is back in 2014 b/c largest workforce is split off; value in RIOT to have Ariel under same umbrella. Historical: Firefox servo, an experimental Rust browser, got integrate back. Apart from firing Rust devs, that was successful. As RIOT, should aim for getting this back.
chrysn: would like to see this all under the RIOT umbrella. Can share fruitfully CI burdens, infra, and code; Teufelchen’s example of URI parsing is great, planning to port over coapcore. Already sharing ideas, community and PR’d code. Let’s take road together.
emmanuel: Back in RIOT-rs days, our aim has been to propose a collaborative code base for Rust + C; Still is the case with Ariel OS. I concur with chrysn and Kaspar on still lot of potential sharing. Aimed for sharing from the start, let’s follow that and make it work.
Kaspar: What Ariel does not have is HIL testing; gotta beef that up. That’s a natural collaboration point.

chrysn: On HIL, got contacted by upcoming commercial provider who might sponsor more on that.

Task Forces, Status

(Teufelchen)


Teufelchen: Apparently we have them? Never saw them, never interacted with them. What’s the status fo that thing? Take garbage out?
chrysn: List looks like “take the garbage out”.
…
Oleg: Task Force has been a proven concept, but nothing active right now. HBO keeping this as “all TFs are somehow concluded right now”?
Teufelchen: It’s also in doxygen and docs.riot-os.org; clutters experience for newcomers when disused concept is explained.
Kaspar: There was subsystem maintainer thing at some point. Also: Talked about TFs report on VMAs; that’s somethign to get back to.
Martine: Would like to call one into life to clean up documentation; that TF is just not documented.
maribu: We did not call it a task force, but we should create a doc task force.
Martine: Should be.
Karl: Just move TFs to abandoned?
Emmanuel: Just removed website revamp – done. On recent/new TFs: Do we TF for interaction Ariel-RIOT?
chrysn: Probably not the right tool here; overlap in people is there, and as long as people are aware of both OSs being around and know whom to poke when anything interesting comes up.
maribu: We could just re-open the dormant doc task force: Documentation Task Force (DocTF) · RIOT-OS/RIOT Wiki · GitHub
Martine: Task of that task force long concluded. This was about creating the API doc in the first place.


Teufelchen: Can we rm explanation of TFs in newcomer docs? Community Processes
chrysn: +1
Oleg: That’s about all community processes, not just newcomers.
chrysn: Replace with “We sometimes form task forces for concrete tasks” (maybe w/ link to wiki if that stays maintained)
Oleg: WFM. Just not drop it completely.

AOB


(none)
Martine: Audio experience this time was very bad, but maybe next time its better…
(yeah, meetecho would be awesome to have)
((or just any tool that does not randomly mute 1/3 of participants for some other participants ^^))