Skip to content

add last meeting minutes and IRC logs #303

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 5, 2019
Merged

add last meeting minutes and IRC logs #303

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
188 changes: 188 additions & 0 deletions minutes/2019-01-29.irc.log
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,188 @@
2019-01-29 20:05:31 ~japaric ok, let's start this meeting
2019-01-29 20:05:40 * therealprof feels the sudden desire to add releases to the agenda
2019-01-29 20:05:53 ~japaric therealprof: releases?
2019-01-29 20:06:22 @therealprof For some of the crates releases are long overdue IMHO.
2019-01-29 20:06:42 @therealprof svd2rust, cortex-m, embedded-hal are the first coming to mind
2019-01-29 20:06:44 ryankurte svd2rust and embedded-hal?
2019-01-29 20:06:49 ~japaric therealprof: we don't have many items on the agenda so you can add a bullet
2019-01-29 20:07:07 ~japaric ok, first some announcements
2019-01-29 20:07:33 Jacob_____ (lurking as usual)
2019-01-29 20:07:39 @adamgreig o/ sorry was wrapping up some work stuff
2019-01-29 20:08:11 ~japaric next week is Rust All Hands, in Berlin. jamesmunns, therealprof and I will be attending, presenting the list of prioritized of rust requests, and discussing wg crates issues
2019-01-29 20:08:59 theJPster_ Which days?
2019-01-29 20:09:20 ~japaric theJPster_: the event is Mon->Fri next week
2019-01-29 20:10:02 theJPster_ Oh, wow.
2019-01-29 20:10:46 @therealprof My thought exactly. :-D
2019-01-29 20:10:57 ~japaric ok, the other announcement is related to MaybeUninit
2019-01-29 20:11:16 ~japaric I suggested stabilizing the uninitialized, as_ptr and as_mut_ptr API ahead of the rest of the API
2019-01-29 20:11:31 ~japaric since that would unblock several use cases on stable
2019-01-29 20:11:39 @therealprof +1
2019-01-29 20:11:46 ~japaric it seems to have received good reception from the people in charge of the stabilization issue
2019-01-29 20:11:53 * japaric trying to find a link to his comment
2019-01-29 20:12:36 ~japaric https://github.com/rust-lang/rust/issues/53491#issuecomment-456348827
2019-01-29 20:12:40 ~japaric you can read from there
2019-01-29 20:12:55 ~japaric there are still a few issues that need to be addressed first
2019-01-29 20:13:10 ~japaric mainly these two: https://github.com/rust-lang/rust/issues/53491#issuecomment-456787477
2019-01-29 20:13:39 ~japaric then we might see MaybeUninit on stable in a few months
2019-01-29 20:13:44 @therealprof There's a lot of stuff happening at the moment towards stabilation like using it in libstd/libcore/liballoc.
2019-01-29 20:14:27 ~japaric using MaybeUninit internally in in libstd/libcore/liballoc, you mean?
2019-01-29 20:15:09 @therealprof Yes.
2019-01-29 20:15:59 ~japaric I don't think that's a blocker for stabilizing a minimal subset of the API though
2019-01-29 20:16:26 ~japaric ok, moving onto the agenda
2019-01-29 20:16:26 @therealprof Certainly not. Just saying there's a good drive at the moment.
2019-01-29 20:16:31 ~japaric ack
2019-01-29 20:16:40 ~japaric first item is rust-embedded/cortex-m-rt#139
2019-01-29 20:16:48 ~japaric I think korken89 is not around today
2019-01-29 20:17:05 @therealprof Nope.
2019-01-29 20:17:19 ~japaric anyone got around to drafting a bug report for this?
2019-01-29 20:17:41 @adamgreig i thought i saw something upstream for it but can't find it now
2019-01-29 20:18:04 @therealprof Yeah, I thought there's an older issue lying around.
2019-01-29 20:18:08 @adamgreig it's causing a lot of woe though
2019-01-29 20:18:13 @therealprof nagisa might know
2019-01-29 20:19:10 Yatekii we just need to get rid of GDB and issue solved :P
2019-01-29 20:19:43 ~japaric adamgreig: if you find the upstream issue could you post in on the cortex-m-rt issue?
2019-01-29 20:20:09 ~japaric if there isn't one we should open a new issue
2019-01-29 20:20:09 @adamgreig will do; I note korken89's comment from the 8th says we will open an upstream issue once we have enough data
2019-01-29 20:20:17 @adamgreig https://github.com/rust-embedded/cortex-m-rt/issues/139#issuecomment-452436495
2019-01-29 20:20:32 @adamgreig not sure if korken89 had any update since then
2019-01-29 20:20:40 nagisa wazzup
2019-01-29 20:21:17 ~japaric nagisa: hello. do you want if there's a rust-lang/rust issue for lr being used / overwritten in noreturn functions?
2019-01-29 20:21:28 ~japaric do you know if**
2019-01-29 20:21:58 nagisa no
2019-01-29 20:22:21 nagisa I do not expect that to be fixed even if filled
2019-01-29 20:22:46 nagisa the best that could possibly happen is an attribute that would override the noreturn annotation for `-> !` functions.
2019-01-29 20:23:26 ~japaric nagisa: do you think an llvm codegen option to preserve lr in these functions would be an option?
2019-01-29 20:23:27 @adamgreig the problem function is in libcore though
2019-01-29 20:23:35 @adamgreig so a user attribute wouldn't help much
2019-01-29 20:23:53 ~japaric (though that would be llvm work and not rustc work)
2019-01-29 20:24:41 theJPster_ Can we at least put a finite backtrace limit in the default .gdbinit file / the documentation?
2019-01-29 20:24:58 ~japaric theJPster_: we can do that in the cortex-m-quickstart template
2019-01-29 20:26:58 ~japaric maybe we could add an unstable flag to not add the noreturn attribute to divergent functions
2019-01-29 20:27:03 theJPster_ Should I open another issue for that?
2019-01-29 20:27:09 ~japaric kind of just for debugging
2019-01-29 20:27:23 ~japaric theJPster_: please do (in the quickstart issue tracker)
2019-01-29 20:27:28 nagisa a flag is something that could happen, but it would still not affect pre-compiled code.
2019-01-29 20:27:42 ~japaric you are right
2019-01-29 20:28:00 @adamgreig I think the problem is exclusively core::panicking::panic?
2019-01-29 20:28:01 ~japaric (unless pure-mir rlibs)
2019-01-29 20:28:23 ~japaric adamgreig: you will also see this in #[entry]
2019-01-29 20:28:46 @adamgreig hm
2019-01-29 20:28:51 @adamgreig yea, I see, annoying
2019-01-29 20:29:14 @adamgreig shame we don't have a better handle on when this stopped working, if it ever did
2019-01-29 20:29:55 @adamgreig does this not manifest for non-embedded use cases?
2019-01-29 20:29:58 ~japaric nagisa: you mentioned the other day something about using debuginfo (cfi?) to get the backtrace; do you think that could help here?
2019-01-29 20:30:25 ~japaric adamgreig: not in panic=unwind code, which is what most std targets use
2019-01-29 20:30:38 ~japaric you only get noreturn+nounwind attributes with panic=abort
2019-01-29 20:31:19 ~japaric we are at the half hour mark
2019-01-29 20:31:43 theJPster_ Opened https://github.com/rust-embedded/cortex-m-quickstart/issues/65
2019-01-29 20:31:53 ~japaric theJPster_: +1
2019-01-29 20:33:13 ~japaric in any case I think we should still open a rust issue and try to see if adding codegen flags is an option (and if it helps at all)
2019-01-29 20:33:32 ~japaric maybe there are some alternatives that involve debuginfo tweaks
2019-01-29 20:33:35 @adamgreig maybe we could not have noreturn when we have nounwind
2019-01-29 20:33:43 @adamgreig mm
2019-01-29 20:35:46 ~japaric let's check with korken89 next week; I can also ask around about this in the RAH
2019-01-29 20:36:06 ~japaric Hark: around?
2019-01-29 20:36:16 Hark o7
2019-01-29 20:36:30 Hark What do you need?
2019-01-29 20:36:40 ~japaric Hark: you had an item on the agenda from a few weeks ago; want to cover it now?
2019-01-29 20:36:45 Hark Sure
2019-01-29 20:37:18 Hark I may be slightly distracted as I'm in a meeting atm, but I can interact
2019-01-29 20:37:35 nagisa japaric: yes.
2019-01-29 20:38:02 Hark japaric: Should I drive the discussion, or do you want to continue to lead
2019-01-29 20:38:37 nagisa japaric: not sure what exactly the problem is, but if you’re looking to deal with backtrace looking infinite, `.cfi` annotations could easily allow making `-> !` appear as if they were "_start" and there ain’t nothing to unwind past it.
2019-01-29 20:38:54 ~japaric Hark: please drive (if you can't then I can take over)
2019-01-29 20:39:13 Hark I can start, but I'm not sure I can hold court for the full discussion
2019-01-29 20:39:13 nagisa (like not actual _start, but the behaviour that gdb does not unwind past the deepest valid stack frame)
2019-01-29 20:39:22 Hark The shtick basically is the content of https://github.com/rust-embedded/wg/issues/294
2019-01-29 20:39:59 Hark Trying to gather thoughts for simple primitives for moving or sharing data with interrupt handlers
2019-01-29 20:40:24 Hark As currently this is a distinctly non-ideal system involving static mut variables and the bare-metal Mutex
2019-01-29 20:40:56 Hark RTFM does provide a good solution to this, but I'm not totally convinced that it should be required for all applications that want to use interrupts
2019-01-29 20:41:17 Hark There may be use in a very simple primitive that can be used for situations where data does not need to be shared, only moved
2019-01-29 20:42:05 Hark Also thoughts on how to handle driver libraries that may want to encapsualte interrupt handling inside their code, essentially allowing the user application to hand over control of the intterupt to the driver to handle internally
2019-01-29 20:43:43 ~japaric I've seen a few ideas tossed around in the thread; I would like to see some prototypes (outside of cortex-m-*) that people can test out and give feedback on
2019-01-29 20:43:44 theJPster_ I am very keen on finding solutions to this. I feel dirty whenever I use `static mut` variables.
2019-01-29 20:43:47 @adamgreig i haven't had any time to think about this since the github discussion but it remains a really important direction to work in imo, will try and find more time to play with things
2019-01-29 20:44:39 @adamgreig a better-scoped solution is nice but i'd happily settle for concurrently-safe global statics or something in preference to some of the heavier-weight suggestions
2019-01-29 20:45:20 ryankurte yeah v pertinent, the other problem i have found with Mutex based sharing is if you have an os managing them, and no nested-interrupts (-cough- mbedos -cough-) you can't do _anything_ from an interrupt context.
2019-01-29 20:45:21 theJPster_ Or at least something that people haven't previously said "We'd really like that to go away"
2019-01-29 20:46:02 @therealprof I don't think I'm at the right level of Rust mastery yet to tackle such a problem but as a user and promoter I'm very much interested in a solution that feels rusty but is easy to use.
2019-01-29 20:46:09 ryankurte +1
2019-01-29 20:46:15 @adamgreig i'll try to find time to prototype some more ideas
2019-01-29 20:46:27 @adamgreig the discussion on the wg issue is good i think
2019-01-29 20:47:24 @therealprof I don't share the opinion that squeezing out the optimum in performance and guaranteed WCET should be the primary goal for the "light" solution.
2019-01-29 20:47:44 disasm ryankurte: maybe "bottom half" approach can help?
2019-01-29 20:47:48 ryankurte i think it needs to be as _easy_ as c?
2019-01-29 20:48:01 @adamgreig yes: as easy as c, and perfectly safe, please
2019-01-29 20:48:09 @therealprof ryankurte: C is easy? O_O
2019-01-29 20:48:19 @adamgreig sharing data between interrupts and main in c is easy
2019-01-29 20:48:22 @adamgreig not necessarily safe
2019-01-29 20:48:46 @therealprof Yeah, maybe more messy. ;)
2019-01-29 20:48:54 ryankurte therealprof: i've written a lot of c
2019-01-29 20:49:08 @therealprof ryankurte: I do it every day. ;)
2019-01-29 20:49:18 ryankurte ^_^
2019-01-29 20:49:28 @adamgreig with an rtos it's usually both, e.g. signalling a thread with a semaphore from an isr: you can scope the static to your translation unit, functions accessing it are thread-safe (usually via locks or atomics), and your isr just calls like "signal_semaphore(&some_static);" while your main thread is "wait_for_semaphore(&some_static)"
2019-01-29 20:49:33 @adamgreig but i think that's basically what rtfm gives you too
2019-01-29 20:49:46 @therealprof For embedded things Rust is already much easier to use than C.
2019-01-29 20:49:51 @adamgreig what we're looking for is something simple and generally-applicable enough to build in to c-m-rt
2019-01-29 20:50:15 Yatekii therealprof: you think so? oO :P
2019-01-29 20:50:29 ~japaric 10 mins left
2019-01-29 20:50:39 ryankurte adamgreig: the nvic module is a neat idea?
2019-01-29 20:50:46 @therealprof Yatekii: Yes.
2019-01-29 20:50:52 ~japaric let's check back on this issue in a few weeks
2019-01-29 20:50:59 @adamgreig ryankurte: i was about to say i'm specifically unsure about that :P since it requires knowing about nvic which is a cortex-m thing and 'higher level' than c-m-rt imo
2019-01-29 20:51:03 ~japaric hopefully there should be some prototypes up by then
2019-01-29 20:51:14 @adamgreig yea
2019-01-29 20:51:18 * therealprof hopes
2019-01-29 20:51:24 Lokathor Open hour?
2019-01-29 20:51:32 ~japaric therealprof: you got the last item on the agenda
2019-01-29 20:51:40 @therealprof Okay.
2019-01-29 20:51:41 @adamgreig Lokathor: not yet :P
2019-01-29 20:52:00 ~japaric are we talking about minor releases or patch releases?
2019-01-29 20:52:08 @adamgreig that is my question too
2019-01-29 20:52:18 @adamgreig how badly does a minor c-m release break the ecosystem?
2019-01-29 20:52:25 ~japaric patch releases shouldn't need a discussion
2019-01-29 20:52:26 @therealprof We've had a lot of discussions and issues tackled in the last months but for some reason we're not quite release happy.
2019-01-29 20:52:29 @adamgreig because we have three or four PRs waiting for the minor release
2019-01-29 20:52:33 @adamgreig and one thing on a patch
2019-01-29 20:52:36 @therealprof minor releases
2019-01-29 20:52:52 @adamgreig but i can't remember how badly minor c-m releases ruin everything
2019-01-29 20:52:57 @adamgreig because of singletons and stuff
2019-01-29 20:52:59 ~japaric adamgreig: you can use semver hack on c-m -- as long as you don't increase MSRV -- so not much of a problem
2019-01-29 20:53:04 @adamgreig ok
2019-01-29 20:53:11 ~japaric (iirc)
2019-01-29 20:53:14 Lokathor I don't have a lot to say for open hour except that I want +thumb and -thumb because it helps me personally :P
2019-01-29 20:53:18 @therealprof I think we should make a decision and effort of coordination to create those releases.
2019-01-29 20:54:27 @therealprof svd2rust has changed quite a bit and I think there's a lot of good stuff in it already. Is there anything people would definitely want to have in a minor release?
2019-01-29 20:54:45 ~japaric does it *need* a minor release?
2019-01-29 20:55:06 @therealprof I think so, yes.
2019-01-29 20:55:19 ryankurte therealprof: it'd be nice to close out some of the open / completed PRs first, but in principle agreed
2019-01-29 20:55:36 ~japaric (svd2rust unreleased changelog is empty :sadface:)
2019-01-29 20:56:38 @therealprof Can we maybe set an action point for every one to check the open and closed PR to form an opinion until next week?
2019-01-29 20:56:41 ryankurte japaric: iirc this will be the release that integrates the fairly major svd rewrite
2019-01-29 20:57:06 ryankurte therealprof: sounds excellent, shall we create a release issue?
2019-01-29 20:57:28 ryankurte s/rewrite/refactor/
2019-01-29 20:58:09 ~japaric ryankurte: but did it change the generated api? or is there a fear of bugs introduced by the refactor? if the later we can do a .alpha / .beta pre-release
2019-01-29 20:58:53 ~japaric *patch* pre-release, if there are no breaking changes
2019-01-29 20:59:46 Lokathor adamgreig, whoops gotta go. Good luck with open hour
2019-01-29 21:00:08 @therealprof japaric: +1
2019-01-29 21:00:37 SEGFAULT this is my first time lurking in this IRC. What's open hour?
2019-01-29 21:01:24 @adamgreig therealprof: we should probably do some more general triage of open issues/prs across wg repos...
2019-01-29 21:01:42 @adamgreig SEGFAULT: we've been trying out having an hour after the official meeting for general chat/show-and-tell/etc
2019-01-29 21:01:47 @therealprof ryankurte: What do we do about embedded-hal? Release is long overdue…
2019-01-29 21:01:51 @therealprof adamgreig: +ü1
2019-01-29 21:01:55 @therealprof +1, even
2019-01-29 21:02:02 ryankurte mostly the latter, but i'd have to check. iirc wez has been running svd2rust with a patch up
2019-01-29 21:02:14 ryankurte therealprof: yeah, totes is
2019-01-29 21:02:40 ryankurte we haven't resolved the v1/v2 compat thing yet though
2019-01-29 21:02:51 @therealprof ryankurte: I thought we have?
2019-01-29 21:02:55 ryankurte (for the digital traits)
2019-01-29 21:03:05 @therealprof Yeah, I know. ;)
2019-01-29 21:03:19 ryankurte (for other readers just in case, soz)
2019-01-29 21:03:38 ryankurte it's not merged, and i made an attempt at implementing the approach i proposed and got stuck in recursive trait nightmares.
2019-01-29 21:03:40 ~japaric we are over time. can we get a volunteer(s) to open release discussion issues for c-m, svd2rust, etc?
2019-01-29 21:03:56 SEGFAULT adamgreig: should I stay quiet then?
2019-01-29 21:03:58 ~japaric questions to answer: does this need a minor release? what could be included in a minor release?
2019-01-29 21:04:28 @therealprof japaric: Will do.
2019-01-29 21:04:32 ryankurte +1
2019-01-29 21:04:37 ~japaric therealprof: thanks
2019-01-29 21:04:52 ~japaric ok, that concludes the meeting. Thanks everyone for attending!
27 changes: 27 additions & 0 deletions minutes/2019-01-29.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
# Embedded WG

- [Coordination repository](https://github.com/rust-embedded/wg)
- [Milestone issues](https://github.com/search?q=org%3Arust-embedded++is%3Aopen+milestone%3A2018&type=Issues)
- Meetings: Tuesdays 8 PM Europe/Berlin time - #rust-embedded @ irc.mozilla.org
# Attendance

**Write your GH username or IRC handle here!**

- japaric
- therealprof
- ryankurte
- posborne
- thejpster
- jrozner
- adamgreig
- Yatekii
- disasm



# Agenda
## Backlog
- korken89: [rust-embedded/cortex-m-rt#139](https://github.com/rust-embedded/cortex-m-rt/issues/139)
- [HarkonenBade](https://github.com/HarkonenBade) [japaric/bare-metal#15 /](https://github.com/japaric/bare-metal/pull/15) https://github.com/rust-embedded/wg/issues/294
- therealprof: Attack plan for some releases of WG owned crates: cortex-m, svd2rust, embedded-hal