[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGS_qxqVUmjxULZ_Kt-gWRJb=+EYpG2_K89sQTq0BYbUighn5w@mail.gmail.com>
Date: Sat, 1 Oct 2022 11:00:14 -0700
From: Daniel Latypov <dlatypov@...gle.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: brendanhiggins@...gle.com, davidgow@...gle.com,
linux-kernel@...r.kernel.org, kunit-dev@...glegroups.com,
linux-kselftest@...r.kernel.org, skhan@...uxfoundation.org
Subject: Re: [PATCH 0/4] kunit: more assertion reworking
On Sat, Oct 1, 2022 at 3:15 AM Miguel Ojeda
<miguel.ojeda.sandonis@...il.com> wrote:
>
> On Sat, Oct 1, 2022 at 2:26 AM Daniel Latypov <dlatypov@...gle.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
Powered by blists - more mailing lists