Hello!

These patches extract and enhance the bitfield support in the register macro in
nova to define Rust structures with bitfields. It then moves out the bitfield
support into the kenrel crate.

Since v5, I dropped several patches and only kept the simple ones that do code
movement, added a few features and added a KUNIT test. After Alex's bounded
integer [1] support is in, we can rewrite the dropped patches.

I also dropped the MAINTAINER entry for now, pending more clarity around that.
I am happy to maintain it, but I need more input on who all will co-maintain,
now that the last 4 patches were dropped. Perhaps we can maintain it was a part
of the core rust-for-linux? I suggest let us create the maintainer entry once
Alex's bounded integer support is integrated but I am open to suggestions.

Here are the v5 patches [2].

[1] https://lore.kernel.org/all/20251002-bounded_ints-v1-0-dd60f5804ea4@nvidia.com/
[2] https://lore.kernel.org/all/20250930144537.3559207-1-joelagnelf@nvidia.com/

Joel Fernandes (5):
  nova-core: bitfield: Move bitfield-specific code from register! into
    new macro
  nova-core: bitfield: Add support for different storage widths
  nova-core: bitfield: Add support for custom visiblity
  rust: Move register and bitfield macros out of Nova
  rust: bitfield: Add KUNIT tests for bitfield

 drivers/gpu/nova-core/falcon.rs               |   2 +-
 drivers/gpu/nova-core/falcon/gsp.rs           |   4 +-
 drivers/gpu/nova-core/falcon/sec2.rs          |   2 +-
 drivers/gpu/nova-core/regs.rs                 |   6 +-
 rust/kernel/bitfield.rs                       | 654 ++++++++++++++++++
 rust/kernel/io.rs                             |   1 +
 .../macros.rs => rust/kernel/io/register.rs   | 301 +-------
 rust/kernel/lib.rs                            |   1 +
 8 files changed, 696 insertions(+), 275 deletions(-)
 create mode 100644 rust/kernel/bitfield.rs
 rename drivers/gpu/nova-core/regs/macros.rs => rust/kernel/io/register.rs (73%)


base-commit: 299eb32863e584cfff7c6b667c3e92ae7d4d2bf9
-- 
2.34.1

On Fri, Oct 03, 2025 at 11:47:43AM -0400, Joel Fernandes wrote:
> Hello!
> 
> These patches extract and enhance the bitfield support in the register macro in
> nova to define Rust structures with bitfields. It then moves out the bitfield
> support into the kenrel crate.
> 
> Since v5, I dropped several patches and only kept the simple ones that do code
> movement, added a few features and added a KUNIT test. After Alex's bounded
> integer [1] support is in, we can rewrite the dropped patches.
> 
> I also dropped the MAINTAINER entry for now, pending more clarity around that.
> I am happy to maintain it, but I need more input on who all will co-maintain,
> now that the last 4 patches were dropped. Perhaps we can maintain it was a part
> of the core rust-for-linux? I suggest let us create the maintainer entry once
> Alex's bounded integer support is integrated but I am open to suggestions.
> 
> Here are the v5 patches [2].
> 
> [1] https://lore.kernel.org/all/20251002-bounded_ints-v1-0-dd60f5804ea4@nvidia.com/
> [2] https://lore.kernel.org/all/20250930144537.3559207-1-joelagnelf@nvidia.com/

Hi Joel,

I returned back to v5 today to just find that you have posted a v6.

There's just 3 days between the versions, and I'm pretty sure most
people were not able to even read the material. Moreover, there's
an -rc1 window ongoing, which means that people may be busy.

You're still receiving feedback to v5, and this makes even more mess
because now I'm completely lost about what I should review and what
should ignore.

Please allow a usual 2 weeks between versions to let people have
a chance to give you a valuable feedback.

It seems that you decided to drop some material, comparing to v5, but
don't even notice what exactly has been removed, except that vague
"code movement and few features" notice.

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.

On maintenance: no core functionality can be merged unmaintained - it's
a strict rule. While in drivers, bitfields are maintained by the nova
maintainers as part of the driver. If you make it a generic library,
you need to define a responsible person(s) in advance. It's also a good
practice to add a core maintainer as a reviewer or co-maintainer. Alice
and Burak added me for bitmap/rust because I already look after bitmaps
in C. You can do the same for bitfields, for the same reason.

It looks like you have some offline discussions on the bitfields.
(Particularly with me.) Before we move forward, can you please wrap
up all the input you've got, so we'll all be sure that we are on the
same page. Right now the process look really messy.

Thanks,
Yury

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. :)

IIUC your remaining concern is with the possible loss of data when
setting a field that is smaller than its primitive type? That should be
addressed by [0], but as it introduces a new core feature I expect some
discussion to take place before it can be merged. In the meantime, it
would be great if we can make the register macro available.

Because letting it fully mature within nova-core also has the drawback
that we might miss the perspective of other potential users, which may
make us draw ourselves into a corner that will make the macro less
useful generally speaking. We are at a stage where we can still make
design changes if needed, but we need to hear from other users, and
these won't come as long as the macro is in nova-core.

[0] https://lore.kernel.org/rust-for-linux/20251002-bounded_ints-v1-0-dd60f5804ea4@nvidia.com/

> On maintenance: no core functionality can be merged unmaintained - it's
> a strict rule. While in drivers, bitfields are maintained by the nova
> maintainers as part of the driver. If you make it a generic library,
> you need to define a responsible person(s) in advance. It's also a good
> practice to add a core maintainer as a reviewer or co-maintainer. Alice
> and Burak added me for bitmap/rust because I already look after bitmaps
> in C. You can do the same for bitfields, for the same reason.

We can assume maintainership of this of course, but is there a problem
if this falls under the core Rust umbrella? As this is a pretty core
functionality. Miguel and other core folks, WDYT?

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. :)
> 
> IIUC your remaining concern is with the possible loss of data when
> setting a field that is smaller than its primitive type? That should be
> addressed by [0], but as it introduces a new core feature I expect some
> discussion to take place before it can be merged. In the meantime, it
> would be great if we can make the register macro available.
> 
> Because letting it fully mature within nova-core also has the drawback
> that we might miss the perspective of other potential users, which may
> make us draw ourselves into a corner that will make the macro less
> useful generally speaking. We are at a stage where we can still make
> design changes if needed, but we need to hear from other users, and
> these won't come as long as the macro is in nova-core.

Hi Alexandre,

Thanks for the broader perspective.

So if there's another user for register!(), then yeah - it's worth to
move it out of the nova earlier. It doesn't mean that we need to split
bitfields out of it immediately.
 
> [0] https://lore.kernel.org/rust-for-linux/20251002-bounded_ints-v1-0-dd60f5804ea4@nvidia.com/

This resembles the _BitInt from C23 standard, and it looks quite
reasonable to me. I'll get back to your RFC shortly.

https://en.cppreference.com/w/c/language/arithmetic_types.html

--

I'm glad that we started this discussion. From my point, what happens now
is inventing the whole new language, and basic bit operations is the heart
of it.

I would really like to avoid adopting an API that will frustrate people
for decades after invention. Please read the following rant to taste
exactly what I mean:

https://lore.kernel.org/all/CAHk-=whoOUsqPKb7OQwhQf9H_3=5sXGPJrDbfQfwLB3Bi13tcQ@mail.gmail.com/

Thanks,
Yury

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@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

On Tue, Oct 07, 2025 at 06:41:58PM -0300, Daniel Almeida wrote:
> 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@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.

Not sure I understand this. Does it mean that you have use cases
for bitfields unrelated to I/O registers? Can you please share
details on what you need and sketch some examples? Particularly,
do you have arrays of bitfields in mind?

If my understanding is correct, then I think the strategy that
meets your interests at best would be moving the registers out of
Nova earlier. After that both Tyr and Nova people will get equally
involved in bitfields (and possible BoundedInt) development.

This is what Danilo proposed in the other email, and I agree that it's
the most structured path.

Regarding timeline, I think 2-stage approach will eventually become
faster.

Thanks,
Yury

On Tue Oct 7, 2025 at 12:36 PM CEST, Alexandre Courbot wrote:
> Because letting it fully mature within nova-core also has the drawback
> that we might miss the perspective of other potential users, which may
> make us draw ourselves into a corner that will make the macro less
> useful generally speaking. We are at a stage where we can still make
> design changes if needed, but we need to hear from other users, and
> these won't come as long as the macro is in nova-core.

There are two different things here that are getting mixed up a bit.

  (1) Moving the register!() code out of nova-core to make it accessible for
      other drivers.

  (2) Generalize the bitfield implementation that so far is baked into the
      register!() code.

Both of those make sense, but they don't have to happen at the same time
necessarily.

Now, I'm not saying that we necessarily have to change the approach here. The
current merge window isn't even closed, so we have plently of time left, i.e.
there's no rush with with patch series.

However, if it helps, I'm perfectly fine to take the register!() implementation
into the I/O entry in a first step and in a second step generalize the bitfield
implementation and move it out of the register!() code.

Again, there's no rush as far as I'm concerned, yet the latter approach might
add a bit more structure and hence run a bit smoother.

- Danilo

Danilo, Yuri, Miguel, John, all,

On 10/7/2025 9:16 AM, Danilo Krummrich wrote:
> On Tue Oct 7, 2025 at 12:36 PM CEST, Alexandre Courbot wrote:
>> Because letting it fully mature within nova-core also has the drawback
>> that we might miss the perspective of other potential users, which may
>> make us draw ourselves into a corner that will make the macro less
>> useful generally speaking. We are at a stage where we can still make
>> design changes if needed, but we need to hear from other users, and
>> these won't come as long as the macro is in nova-core.
> 
> There are two different things here that are getting mixed up a bit.
> 
>   (1) Moving the register!() code out of nova-core to make it accessible for
>       other drivers.
> 
>   (2) Generalize the bitfield implementation that so far is baked into the
>       register!() code.
> 
> Both of those make sense, but they don't have to happen at the same time
> necessarily.
> 
> Now, I'm not saying that we necessarily have to change the approach here. The
> current merge window isn't even closed, so we have plently of time left, i.e.
> there's no rush with with patch series.
> 
> However, if it helps, I'm perfectly fine to take the register!() implementation
> into the I/O entry in a first step and in a second step generalize the bitfield
> implementation and move it out of the register!() code.
> 
> Again, there's no rush as far as I'm concerned, yet the latter approach might
> add a bit more structure and hence run a bit smoother.

In my view it is better to move both bitfield and register macros together
because if we only moved register, it means we would have no bitfield support
for the page table / mm use case I just posted a patch for (which is why I
started looking into Bitfield support initially) unless we create a copy of just
the bitfield code within nova which we definitely shouldn't I think. So I think
it is best to move both.

I think we can address Yuri’s concerns shortly. All the outstanding concerns
(including Yuri's) are as follows (and sorry Yuri to send the v6 when we were
still discussing v5, but please let me know if I missed anything):

1. Undefined bitfields to be zero'ed to avoid undefined behavior:  Unlike C,
this is not a concern in Rust because we will be *defining* the raw value
explicitly as an inner integer. In register! macro usecases in fact, we do
store/read the entire inner value some times so we have to support that (without
zero'ing).

2. The setter API should fail or trim inputs based on the (un)defined bitfields:
This should not be an issue after Alex's idea on moving this issue to the type
system [1]. The compilation simply fails for invalid inputs.

3. Build pattern chaining of .set_XX(...).set_YY(...):  Yuri requested to drop
this. I discussed with Alex and we feel this is idiomatic rust and we ought to
support it.

4. Concerns about "a.set_foo(XX)" pattern ignoring returning value resulting in
a NOOP: Mark the setter API #[must_use] to prevent patterns where the return
value is discarded, ex: a.set_foo(XX);

5. MAINTAINERS file updates: Miguel and Yuri replied to this so we can adopt
their guidance. Currently I am considering Alex and me as M: and Yuri as R:. For
git tree, let me know which tree we want to use or could create a new one. For
the IO (register macro) change, I can add add an entry to the existing IO record.

Does this all sound good? If not please raise your concern as a reply and let us
discuss it.

As next steps, the only thing left is to address #2 (unless anyone replies with
any objections). However, IMO #2 can be addressed once the code moves out as
well (it might be a bit of time as we need the bounded int changes in case we
want to address #2 before moving code outside of nova). Thoughts? Everything
else above (expect #2) is good to go and I can roll it into v7 soon.

Any other thoughts or concerns? Thanks.

[1] https://lore.kernel.org/all/20251002-bounded_ints-v1-0-dd60f5804ea4@nvidia.com/

On Tue Oct 7, 2025 at 11:08 PM CEST, Joel Fernandes wrote:
> Danilo, Yuri, Miguel, John, all,
>
> On 10/7/2025 9:16 AM, Danilo Krummrich wrote:
>> On Tue Oct 7, 2025 at 12:36 PM CEST, Alexandre Courbot wrote:
>>> Because letting it fully mature within nova-core also has the drawback
>>> that we might miss the perspective of other potential users, which may
>>> make us draw ourselves into a corner that will make the macro less
>>> useful generally speaking. We are at a stage where we can still make
>>> design changes if needed, but we need to hear from other users, and
>>> these won't come as long as the macro is in nova-core.
>> 
>> There are two different things here that are getting mixed up a bit.
>> 
>>   (1) Moving the register!() code out of nova-core to make it accessible for
>>       other drivers.
>> 
>>   (2) Generalize the bitfield implementation that so far is baked into the
>>       register!() code.
>> 
>> Both of those make sense, but they don't have to happen at the same time
>> necessarily.
>> 
>> Now, I'm not saying that we necessarily have to change the approach here. The
>> current merge window isn't even closed, so we have plently of time left, i.e.
>> there's no rush with with patch series.
>> 
>> However, if it helps, I'm perfectly fine to take the register!() implementation
>> into the I/O entry in a first step and in a second step generalize the bitfield
>> implementation and move it out of the register!() code.
>> 
>> Again, there's no rush as far as I'm concerned, yet the latter approach might
>> add a bit more structure and hence run a bit smoother.
>
> In my view it is better to move both bitfield and register macros together
> because if we only moved register, it means we would have no bitfield support
> for the page table / mm use case I just posted a patch for (which is why I
> started looking into Bitfield support initially) unless we create a copy of just
> the bitfield code within nova which we definitely shouldn't I think. So I think
> it is best to move both.

Again, fine for me either way, but I wanted to open the possibility.

Typically, things run more smoothly when focusing on one thing at a time.
Especially when one thing is done to unblock something else, while the other
things needs some more discussion and might require a more slow-paced approach.)

(Slightly off-topic: Regarding the bitfields for page table management: Are we
sure that we can use raw bitfields for this? I.e. will we always be able to
configure the GPU to match CPU endianness?)

> For the IO (register macro) change, I can add add an entry to the existing IO
> record.

I don't think any changes are needed, it should be covered by just moving it to
rust/kernel/io/register.rs.

Thanks,
Danilo

On Wed, Oct 08, 2025 at 12:08:59AM +0200, Danilo Krummrich wrote:

> Regarding the bitfields for page table management: Are we
> sure that we can use raw bitfields for this?

As per my current understanding we can't. Bitfields are not suitable for
direct I/O and considered as a data storage. In the current scheme:

        regs::NV_PFALCON_FALCON_DMATRFBASE::default()
            .set_base((dma_start >> 8) as u32)
            .write(bar, &E::ID);

we account for endianess in the .write() method, which would be a part
of register API, not bitfields.

FYI: ARM64 is in process of dropping BE, and Linus announced the end
of BE support for RISC-V:

https://lore.kernel.org/all/CAHk-=wgYcOiFvsJzFb+HfB4n6Wj6zM5H5EghUMfpXSCzyQVSfA@mail.gmail.com/

Thanks,
Yury

On Wed Oct 8, 2025 at 4:28 PM CEST, Yury Norov wrote:
> On Wed, Oct 08, 2025 at 12:08:59AM +0200, Danilo Krummrich wrote:
>
>> Regarding the bitfields for page table management: Are we
>> sure that we can use raw bitfields for this?
>
> As per my current understanding we can't. Bitfields are not suitable for
> direct I/O and considered as a data storage. In the current scheme:
>
>         regs::NV_PFALCON_FALCON_DMATRFBASE::default()
>             .set_base((dma_start >> 8) as u32)
>             .write(bar, &E::ID);
>
> we account for endianess in the .write() method, which would be a part
> of register API, not bitfields.

I know, I proposed this register API design about a year ago, and Alex came up
with an awesome implementation for it. :)

And yes, your understanding is correct, the idea is that the I/O backend that
knows about the underlying bus, etc. takes care of the endianess.

However, we might still be able to use bitfields natively for page table
management structures: In [1] I asked for the NV_PMC_BOOT_1 register, which
might provide some endianess switch to ensure that we always match CPU
endianess.

> FYI: ARM64 is in process of dropping BE, and Linus announced the end
> of BE support for RISC-V:

Yeah, I'm aware of the thread. Also note that for RISC-V it was also clarified
that if it turns out that BE for RISC-V becomes relevant it would also find its
way into the kernel. If that's likely is of course a different question.

However, there are still architectures such as s390x that could be supported.

So, long story short, my question from above is more meant to challenge if we
can really always guarantee that CPU and GPU endianess match for nova-core.

[1] https://lore.kernel.org/lkml/DDCV84IJHUML.126CB1CT0XMX5@kernel.org/

On Tue, Oct 7, 2025 at 12:36 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> We can assume maintainership of this of course, but is there a problem
> if this falls under the core Rust umbrella? As this is a pretty core
> functionality. Miguel and other core folks, WDYT?

I think what Yury may mean is that this should get an explicit
`MAINTAINERS` subentry even if it falls under `rust/kernel/` -- I
agree that is a good idea.

Thanks!

Cheers,
Miguel

On Tue Oct 7, 2025 at 7:42 PM JST, Miguel Ojeda wrote:
> On Tue, Oct 7, 2025 at 12:36 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>>
>> We can assume maintainership of this of course, but is there a problem
>> if this falls under the core Rust umbrella? As this is a pretty core
>> functionality. Miguel and other core folks, WDYT?
>
> I think what Yury may mean is that this should get an explicit
> `MAINTAINERS` subentry even if it falls under `rust/kernel/` -- I
> agree that is a good idea.

Ack - how do you expect things to work in terms of code flow? Do we need
to have a dedicated tree and send you pull requests? If so, should we
host it under the Rust-for-Linux Github org?

On Tue, Oct 7, 2025 at 3:21 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> Ack - how do you expect things to work in terms of code flow? Do we need
> to have a dedicated tree and send you pull requests? If so, should we
> host it under the Rust-for-Linux Github org?

In general, if there is a better tree (i.e. an existing C subsystem),
then what we always do is ask those maintainers first.

But, otherwise, if there is no good choice because it is something too
generic/core, then yes, what you propose would be ideal (and it should
be easy since you are already maintainers of other trees etc.).

If the amount of patches ends up being very low, we can skip the tree
and I can take the patches, but PRs are simpler and scale better for
me.

Thanks!

Cheers,
Miguel

On Tue, Oct 07, 2025 at 10:20:54PM +0900, Alexandre Courbot wrote:
> On Tue Oct 7, 2025 at 7:42 PM JST, Miguel Ojeda wrote:
> > On Tue, Oct 7, 2025 at 12:36 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
> >>
> >> We can assume maintainership of this of course, but is there a problem
> >> if this falls under the core Rust umbrella? As this is a pretty core
> >> functionality. Miguel and other core folks, WDYT?
> >
> > I think what Yury may mean is that this should get an explicit
> > `MAINTAINERS` subentry even if it falls under `rust/kernel/` -- I
> > agree that is a good idea.

Exactly. Otherwise we'll end up with a single maintainer for a huge
codebase written by different people for different reasons. This is how
lib/ is maintained now. Not very effective. 
 
> Ack - how do you expect things to work in terms of code flow? Do we need
> to have a dedicated tree and send you pull requests? If so, should we
> host it under the Rust-for-Linux Github org?

(Not sure you've asked me but anyways)

For maintenance hierarchy I'd suggest a structure where an author of
the new subsystem obviously becomes a maintainer, then some acknowledged
Rust person co-maintains it, and lately some non-rust person from a
related kernel subsystem becomes a reviewer or co-maintainer.

In 6.18 we did this for bitmaps, and the maintenance entry looks like:

 BITMAP API [RUST]
 M:     Alice Ryhl <aliceryhl@google.com>
 M:     Burak Emir <bqe@google.com>
 R:     Yury Norov <yury.norov@gmail.com>
 S:     Maintained
 F:     rust/kernel/bitmap.rs
 
Check 11eca92a2cae ("rust: add bitmap API").

Thanks,
Yury

On Oct 3, 2025, at 8:47 AM, Joel Fernandes <joelagnelf@nvidia.com> wrote:

> Hello!
> 
> These patches extract and enhance the bitfield support in the register macro in
> nova to define Rust structures with bitfields. It then moves out the bitfield
> support into the kenrel crate.
> 
> Since v5, I dropped several patches and only kept the simple ones that do code
> movement, added a few features and added a KUNIT test. After Alex's bounded
> integer [1] support is in, we can rewrite the dropped patches.
> 
> I also dropped the MAINTAINER entry for now, pending more clarity around that.
> I am happy to maintain it, but I need more input on who all will co-maintain,
> now that the last 4 patches were dropped. Perhaps we can maintain it was a part
> of the core rust-for-linux? I suggest let us create the maintainer entry once
> Alex's bounded integer support is integrated but I am open to suggestions.
> 
> Here are the v5 patches [2].
> 
> [1] https://lore.kernel.org/all/20251002-bounded_ints-v1-0-dd60f5804ea4@nvidia.com/
> [2] https://lore.kernel.org/all/20250930144537.3559207-1-joelagnelf@nvidia.com/

Reviewed-by: Edwin Peer <epeer@nvidia.com>

Regards,
Edwin Peer