Message ID | 20221001002638.2881842-1-dlatypov@google.com (mailing list archive) |
---|---|
Headers | show |
Series | kunit: more assertion reworking | expand |
On Sat, Oct 1, 2022 at 2:26 AM Daniel Latypov <dlatypov@google.com> wrote: > > Note: this does change the function signature of > kunit_do_failed_assertion, so we'd need to update the rust wrapper in > https://github.com/Rust-for-Linux/linux/blob/rust/rust/kernel/kunit.rs, > but hopefully it's just a simple change, e.g. maybe just like: Yeah, should be simple. Thanks for pointing it out! The series looks like a great cleanup on top of the stack reduction. Cheers, Miguel
On Sat, Oct 1, 2022 at 3:15 AM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > On Sat, Oct 1, 2022 at 2:26 AM Daniel Latypov <dlatypov@google.com> wrote: > > > > Note: this does change the function signature of > > kunit_do_failed_assertion, so we'd need to update the rust wrapper in > > https://github.com/Rust-for-Linux/linux/blob/rust/rust/kernel/kunit.rs, > > but hopefully it's just a simple change, e.g. maybe just like: > > Yeah, should be simple. Thanks for pointing it out! > > The series looks like a great cleanup on top of the stack reduction. Thanks for taking a look at the rest of the series as well. While I have you here, any thoughts on how to coordinate the change? I made the breaking change patch#1 so it should be easier to pull out. One option I was thinking was: * wait till this lands in Shuah's tree * I create a Github PR that contains patch#1 + a patch for kunit.rs I was not clear on how the RfL Github pulls in upstream changes or how often. But my assumption is patch#1 would fall away naturally if rebasing onto 6.1 (and maybe we can squash the kunit.rs change). Thanks, Daniel
On Sat, Oct 1, 2022 at 8:00 PM Daniel Latypov <dlatypov@google.com> wrote: > > While I have you here, any thoughts on how to coordinate the change? My bad, I forgot to reply to this, sorry. I noticed it again when merging 6.1-rc1 into our branch. Normally I fix the issues when I merge back from Linus. Since we intend to keep the CI green on every PR, I added the fix for this in the merge itself. In any case, to clarify, the `rust` branch in GitHub is just where we placed a lot of things that we wanted to eventually submit (and some that should not, e.g. the GitHub CI files). We will be minimizing the differences w.r.t. upstream in that branch by preparing proper patches from scratch and submitting them through `rust-next` and other trees, and eventually remove it (or reusing the name for the fixes branch since that is the name other trees use, but we will see). Cheers, Miguel
On Tue, Oct 18, 2022 at 4:20 PM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > On Sat, Oct 1, 2022 at 8:00 PM Daniel Latypov <dlatypov@google.com> wrote: > > > > While I have you here, any thoughts on how to coordinate the change? > > My bad, I forgot to reply to this, sorry. I noticed it again when > merging 6.1-rc1 into our branch. No worries. You've had a very busy couple of weeks, I imagine. > > Normally I fix the issues when I merge back from Linus. Since we > intend to keep the CI green on every PR, I added the fix for this in > the merge itself. Thanks! Daniel
On Wed, Oct 19, 2022 at 1:26 AM Daniel Latypov <dlatypov@google.com> wrote: > > No worries. > You've had a very busy couple of weeks, I imagine. Just a bit :) Nevertheless, it was my intention to reply :( I have linked this thread from the PR noting that you warned me about the future conflict [1], thanks again! [1] https://github.com/Rust-for-Linux/linux/pull/915#issuecomment-1283138279 Cheers, Miguel