# Meeting 2023-08-16 <!-- Leave your topic starting with ### in the relevant sections below --> ## Critical <!-- bugs, soundness issues, urgent patches/reviews etc. --> ## Status Reports <!-- You want to report on something you are working on/request reviews. Or you want to know the status of something someone else is doing --> ## Discussion Questions <!-- Anything that requires lengthy discussion/more general questions also fit here --> ### Bennos's patch series Most patches ready to take, Gary has a comment about array initializer. Waiting for Benno to reply to the email. ### (discuss about upstreaming of char device / platform device) https://github.com/nbdd0121/linux/commit/e2f30596dbb8a0f590b4f35039800519c4f3d8c9 ### Complex macro constant expansion in Clang Background: https://github.com/rust-lang/rust-bindgen/issues/753 John Baublitz: have everything in a function separate by `;` and ask clang to query each macro Gary: How about extreme cases like ```c #define L { #define R } void fun() { L; R; } ``` Miguel: So I originally suggested to create an intermediate file for each macro to expand for that reason (i.e. one does not know if a particular macro expansion will compile or not). John: We only care about ones that expand to literals Gary: But you don't know if a macro is a literal Miguel: Could do an optimistic run first and go one-by-one (or binary search) if it failed. John: The main concern is whether bindgen is willing to take this approach at all. John: Could be a fallback approach only used when c expression can't parse it. John: Background is when C header maintainer decided to switch simple constants to UINT invocation. Miguel: If the clang-based approach works, I would prefer everything to go with that approach. Miguel: Be careful about types, e.g. char or i128 Gary: bindgen is ignoring integer types, seems to be due to i64 usage in cexpr library. Miguel: Also another approach to offer (especially if performance is bad) is to have an opt-in flag. Then users (e.g. the kernel when we have split headers to process) can request it only for those headers where they require it (of course, this does not allow us to drop the `cexpr` dependency). John: I will post in the issue a summary of tradeoffs. ### Website Miguel: Don't want to have email addresses on website, have a `awk`-based approach Gary: `scripts/get_maintainer.pl --norolestats --nol --nogit -f rust` works ### ARM patch (breaking x86 build without explicit ARCH) Miguel: It's breaking build if you don't pass in `ARCH`. So they shouldn't take it. Boqun: History of the ARCH being x86 (instead of x86_64) without explicit ARCH https://lore.kernel.org/all/1356040315.3198.51.camel@shinybook.infradead.org/ Gary: I think's it's intentional to set `ARCH` to be x86 on x64 machine? Miguel: We have `SRCARCH` and `SUBARCH` Boqun: Maybe make ARM special case instead of x86? i.e. make target.json default and target triple non-default Gary: Ideally we want to use target triple everywhere and target.json should be the exception Consensus: use `SRCARCH` for now seems the best approach ## Miscellaneous <!-- stuff that does not fit into other categories -->