From dfc898c607073d403c3fc8f9874fe257f0ed226e Mon Sep 17 00:00:00 2001 From: Hudson Ayers Date: Fri, 21 Apr 2023 11:25:01 -0700 Subject: [PATCH] add core wg notes 2023-04-21 --- doc/wg/core/notes/core-notes-2023-04-21.md | 175 +++++++++++++++++++++ 1 file changed, 175 insertions(+) create mode 100644 doc/wg/core/notes/core-notes-2023-04-21.md diff --git a/doc/wg/core/notes/core-notes-2023-04-21.md b/doc/wg/core/notes/core-notes-2023-04-21.md new file mode 100644 index 0000000000..f41fe2a702 --- /dev/null +++ b/doc/wg/core/notes/core-notes-2023-04-21.md @@ -0,0 +1,175 @@ +# Tock Core Notes 2023-04-21 + +## Attendees +- Hudson Ayers +- Amit Levy +- Leon Schuermann +- Alexandru Radovici +- Branden Ghena +- Tyler Potyondy +- Brad Campbell +- Johnathan Van Why + +## Updates +- Hudson: Alistair asked for folks to look at PR 3360 -- he made some updates + on the PR so now it does not duplicate capsule code and now it just adds new + system call driver numbers. Alistair would appreciate folks taking another + look at that, especially now that it is not a very big change +- Leon: I am still not a huge fan of adding new driver numbers for existing + peripherals if they do not add any new functionality. I still think in the + long-term that we want to have something like a driver registry where we can + actually have semantic meanings for two instances of a driver on a given + board and then a way to request a combination of drivers under a certain + label. I am not opposed to this in the short term though. +- Hudson: Yeah, I think Alistair probably agrees with that but that seems like + something which might still be a good ways off. +- Hudson: We were supposed to continue Alyssa's discussion from last week, but + she is not here today so we will have to defer that agenda item. + +## External Dependencies +- Hudson: We talked a while back about moving forward with external + dependencies in the Tock kernel by starting to split up capsules. Leon got + around to implementing the first split between core and extra, which is + great, but we need to figure out next steps on this. My understanding based + on PR 3346, which is where we initially had some of this discussion on this + issue, is that we want to have an external subcrate outside of the other + capsule crates, and that is where something like Alistair's external + dependency would first live. +- Leon: I had the impression that when we split up capsules our intention was + to sort of gradually start splitting out subsystems for which it is natural + for them to rely on external dependencies, and limit the impact of that by + having boards only rely on crates they require. I think LoRa was maybe an + example where would just have a LoRa crate in the capsules folder. +- Hudson: Yeah, I think the original motivation for this was Alistair wanting + to use ghash for AES-GCM in PR 3092. +- Leon: Yeah I'm recalling this. We had talked about the networking stack being + its own crate and relying on smoltcp potentially. +- Hudson: I think that, recalling some more now, we had a couple options when + we initially discussed this. One was breaking capsules up into a ton of + crates, which people did not like so we did not go that way. This core / + contrib split is more just a nice clean division for now and a roadmap to + splitting up the capsules directory at all. I think we had talked about doing + something like what you described, where every capsule that would require a + unique external dependency would like in its own crate -- that is for + Alistair's example we would have a crate for aes_gcm in the capsules + directory, and only that crate would have an external dependency. +- Leon: I don't think this needs to be a strictly per-capsule basis, but if it + does not make sense for a certain subset of structs in Rust capsules to live + without an external dependency, we should probably draw some fuzzy boundaries + about the precise subsystem that they encapsulate, and make that an external + crate to separate that from the rest of the crates which we maintain. +- Hudson: Ok, yeah. +- Leon: I am not fundamentally opposed to a big external crate, but we don't + want to make it so projects needing one dependency to have to pull in all + dependencies. +- Hudson: I think we should tell Alistair to make a single crate for aes_gcm, + in the capsules directory, which can have a dependency on ghash, and then + opentitan can depend on that capsules. +- Hudson: We can figure out how to broaden the scope of this crate or create + new ones as other external dependencies get added. +- Leon: Yeah I think that sounds like what we had talked about and what I had + envisioned. We need to document this in the external_depenednecies.md file in + this PR. I could give a shot at creating a new version of it which reflects + this design. +- Hudson: Great, I am happy to look through that. +- Brad: Where would this new crate live? +- Hudson: In the capsules directory +- Brad: Is capsules a crate? +- Hudson: No, it is just a directory, core and extra are the two crates within + that. +- Hudson: For external crates, we might want another directory under the + capsules directory, to delineate that all crates within that directory are + separate because they have external dependencies. +- Brad: So how much logic should these new capsules have? +- Hudson: I think basically the minimum amount of logic to get things working + that does not require other capsules to depend on this one. +- Brad: Ah, but this new crate could use say the core capsules? +- Hudson: Yes. +- Leon: I think it is very important that we are not too strict in limiting + what can go in these new crates, that was the motivation for splitting this + up in the first place, since we concluded it is impossible to extract every + crate into its own trait, especially because of issues with macros +- Brad: So these will be full-fledged capsules? +- Hudson: Yes +- Brad: But they are in their own namespace, so the dependency does not + propgate +- Hudson: Yep, exactly, only boards that needs these deps will pay the cost of + them +- Brad: I think this sounds like a nice solution +- Branden: I am sold +- Hudson: I like that we have this one example from Alistair that we can use as + a trial. It is possible there is something we have not considered, so we + should not be married to the initial text of this document, but we can always + make changes based on our experiences. +- Branden: It helps that we do not expect to have a ton of these +- Hudson: Yeah, any maybe we should add some langauge to the document that + makes it clear that we will not just accept any dependency. +- Brad: Do we have in this document anything that outlines the issues with + other approaches, that describe why we chose this one? +- Hudson: No, I don't think so. +- Brad: I will try to draft that up and add it so we keep that knowledge + around. +- Leon: Great, and then we can reconvene on this next week before we ask + Alistair to make changes +- Branden: Put out a call for when you think its ready, I have been ignoring it + for awhile since it has been in limbo +- Leon: I think this is pretty exciting for long standing projects like a + proper BLE stack, for isolated subsystems I think this could be a really + elegant solution. +- Hudson: I agree. I do think we got kinda lucky that Rubble did not end up + being the first dependency that we used this for since it is in maintenance + mode. +- Brad: Sure, but it definitely still informed this notion of board specific + dependencies. +- Leon: I got a prototype working using smoltcp so that could be another thing + to try this with +- Hudson: Yeah, Tyler, you should chat with Leon about Tock networking since + his ethernet work probably has some overlap with what you want to do, + especially regarding TCP and IPv6 + +## Tock World Planning +- Hudson: Brad, thoughts on hosting at UVA? +- Brad: Sure +- Amit: Yeah, the late July time period on the east coast worked best for most + people, and we have not done UVA yet +- Hudson: I am always looking for an excuse to go back to UVA +- Brad: What did we do last year? +- Branden: 1.5 days, but the half day went long +- Amit: I think we can afford a bit longer this time. There might be some + recent industry developments to discuss, and funding stuff. Might be good to + do a training. +- Alex: I can volunteer to do a training +- Amit: That would be great +- Brad: It sounds like 2 days would be a good starting point. +- Hudson: I personally would request that it butt up to a weekend on one end + +## Other Stuff +- Brad: No progress on stable compiler stuff?? +- Hudson: asm\_const is blocked on inline\_asm, which at least seems to be + making some progress +- Brad: I see, just added a link to that to our tracking issue +- Hudson: naked functions unfortunately seems to be totally stalled, and I am + not sure there is a clear path forward there, which is a bummer since it was + looking like it was going to be stabilized just a few months ago. +- Brad: Yeah, I guess let's just keep an eye on it. +- Brad: I have also been thinking about bluetooth. It seems like it is really + hard to add, there is not good support in Rust. I would love any ideas on + what we could do short of writing our own stack (which is not something I can + do). +- Branden: Unfortunately I do not have any ideas +- Hudson: Yeah, there don't seem to be any great Rust libraries out there, the + few that do exist do not inspire confidence. Most projects just seem to link + against C libraries if anything. +- Brad: Has anyone tried just running the nordic softdevice on the network core + of the nrf5340? +- Hudson: Not that I know of, I think even that approach has some memory safety + concerns because both cores can access the same memory I think +- Amit: I think that fundamentally the right way to think of this is as not + that different than a peripheral implementing logic like this in hardware. +- Hudson: Sure, anyway, maybe that is something worth looking into. +- Alexandru: I have students working on ambient light and ADC for libtock-rs. + It looks like these are only implemented for Hail and Imix.Can anyone test? +- Hudson: I am happy to. I also can look into getting you some Imixes + eventually. +- Alexandru: What is a realistic timeline for deciding on TockWorld dates? +- Amit: I am hoping within the next couple of weeks.