Daniel Almeida
2025-Oct-07 21:41 UTC
[PATCH v6 0/5] Introduce bitfield and move register macro to rust/kernel/
Hi, First and foremost I?d like to say sorry for not having the bandwidth to chime in here earlier. I?ve been pretty consumed by Tyr itself lately.> On 7 Oct 2025, at 12:41, Yury Norov <yury.norov at gmail.com> wrote: > > On Tue, Oct 07, 2025 at 07:36:21PM +0900, Alexandre Courbot wrote: >> Hi Yuri, >> >> On Tue Oct 7, 2025 at 7:29 AM JST, Yury Norov wrote: >> <snip> >>> Regardless, I don't think that this is the right path to move the >>> bitfields into the core. The natural path for a feature that has >>> been originally developed on driver side is to mature in there and >>> get merged to core libraries after a while. Resctrl from Intel is one >>> recent example. >>> >>> With that said, I'm OK if you move the bitfields as a whole, like you >>> do in v5, and I'm also OK if you split out the part essential for nova >>> and take it into the driver. In that case the bitfields will stay in >>> drivers and you'll be able to focus on the features that _you_ need, >>> not on generic considerations. >>> >>> I'm not OK to move bitfields in their current (v6) incomplete form in >>> rust/kernel. We still have no solid understanding on the API and >>> implementation that we've been all agreed on. >> >> Initially the plan was indeed to give this code some more time to mature >> in nova-core before moving it out. >> >> The reason for the early move is that we have another driver (Tyr) who >> wants to start using the register macro. Without it, they would be left >> with the option of either reinventing the wheel, or poking at registers >> the old-fashioned way, which I think we can agree is not going to be any >> safer than the current macro. :) >>Tyr could use both register!() and bitfield!() today FYI. If you move it out, I can follow with an actual patch to do so. ? Daniel