Re: [RFC PATCH 0/4] rust: damon: a first small step, plus a Rust prcl sample

[Enze Li]

Hi SJ,

Thank you for the detailed reply.  Comments inline below.

On 9/27/26 18:07, SJ Park wrote:
> Hi Enze,
> 
> On Sun, 27 Sep 2026 15:28:08 +0800 Enze Li <lienze@xxxxxxxxxx> wrote:
> 
>> Hi SJ, hi all,
>>
>> Almost a year ago, right after a memory-leak fix discussion on this list, I
>> asked whether introducing Rust for some DAMON modules could be worth
>> exploring as a proactive measure.  SJ's answer was positive: he was open to
>> Rust adoption in DAMON, both in kernel and user space, and even mentioned
>> he had been wanting to write a Rust sample DAMON module himself since LPC,
>> but had not found the time yet [1].
>>
>> So, here is my attempt at making that start happen.  This RFC is
>> intentionally small: it adds just enough Rust support for DAMON to port the
>> proactive reclamation sample (prcl.c), and nothing more.
> 
> Thank you for this patch series!  Yes, I'm interested in Rust, though I didn't
> have sufficient time to dig in yet.  I'm planning to attend Rust for Linux
> training day [1] on next Sunday.
> 
> TLDR: I feel like we might need to wait or focus on module parameter support in
> Rust, ongoing DAMON extension works before adopting Rust in DAMON.  Also, I'd
> suggest starting with wsse, which is simpler.

Agreed, and after thinking it over I am fine with deferring the series.

For context, the original goal was never really the sample itself: what
I was hoping to start was a thin Rust compatibility layer for DAMON --
the damon.rs wrappers -- with prcl serving only as its first in-tree
user, to validate that the wrappers are usable so that others can build
their own DAMON-based modules on top of them.  It is therefore a bit
unfortunate that the first step ends up blocked partly by something
outside of DAMON, namely the lack of writable/sysfs-backed module
parameters in Rust.

That said, I understand the position and I do not think waiting is the
wrong outcome: the parameters have no committed timeline, and the DAMON
API reconstruction is actively changing the interfaces the wrappers
would sit on, so starting now with a debugfs-only interface we already
know we want to replace would just add churn to moving APIs.

> 
>>
>> The series has four patches:
>>
>>    1. Generate Rust bindings for include/linux/damon.h.
>>    2. Add thin safe wrappers in a new rust::kernel::damon module: contexts,
>>       targets, access patterns, quotas, watermarks, schemes, plus
>>       start/stop.  Everything FFI-related is confined to the wrappers, with
>>       the usual SAFETY comments; error codes are returned as kernel::Result.
>>    3. Add samples/damon/rust_prcl.rs, a Rust port of prcl.c.  It watches the
>>       virtual address space of a target process and pages out cold regions
>>       with the DAMOS_PAGEOUT action, same access-pattern filter as the C
>>       version.
> 
> I'd suggest starting from porting wsse, because it is simplest.  By scoping
> down to it, you could drop the wrappers for DAMOS.
> 
>>    4. Add a MAINTAINERS entry for the two new files.
>>
>> Two differences from the C sample are worth noting.
>>
>> First, the control interface.  The C prcl sample is driven through
>> runtime-writable module parameters (target_pid and enabled, the latter via
>> module_param_cb), neither of which Rust can express yet -- its module
>> parameters are load-time only and do not show up under /sys/module/, and
>> there is no general sysfs abstraction in mainline or the RfL rust-next
>> tree.  The debugfs abstraction, however, already provides the safe
>> read/write wrappers we need, so the Rust sample exposes the same two knobs
>> under /sys/kernel/debug/rust_prcl/.  This is a temporary detour, not a
>> design preference: the sample will be switched over to match the C
>> interface once Rust supports sysfs-backed module parameters.
> 
> Do we have a timeline for module parameters support in Rust?  I'd prefer to
> avoid use of debugfs and directly start with sysfs.

I am not aware of one.  rust-next still registers Rust module
parameters with perm 0 (load-time only).  I will keep an eye on the
rust-for-linux list; if anyone picks it up, I would appreciate being
Cc'd.

> 
>>
>> Second, the functional scope.  The C sample also repeatedly reports the
>> estimated working set size via a repeating damon_call() callback.  This
>> initial Rust version covers only the core monitoring/reclamation path
>> (context, target, PAGEOUT scheme, start/stop); wss reporting needs safe
>> wrappers for damon_call() and region iteration, which will come in a
>> follow-up series that also makes the Rust sample's output match the C
>> one's.
> 
> As I abovely mentioned, I'd prefer porting wsse first, and later extend to
> DAMOS-based samples like prcl and mtier.

Noted -- when this restarts, it will be the wsse-scoped version, without
the DAMOS wrappers, and the compatibility layer will grow around only
what that sample actually needs.

> 
>>
>> A quick word on the longer-term plan, so the design discussion here can
>> happen with the destination in mind:
>>
>>    - Over roughly the next year, I would like to port the other two DAMON
>>      samples (wsse and mtier) to Rust as well, and let the DAMON Rust
>>      compatibility layer grow together with them, wrapping only what real
>>      in-tree users need.
>>    - Once that layer has matured, I would be happy to try Rust for the
>>      production modules - damon/reclaim, damon/lru_sort and damon/stat.
>>      That is a much bigger step, of course, and it only happens if SJ is
>>      comfortable with it.  Consider it a willingness statement, not a
>>      promise.
> 
> I think that's a good plan.  However, I'd like to call out we will also need to
> make each step with good and sufficient discussions.  That is, for each step,
> we will discuss if the previous step change was helpful and therefore make
> sense to proceed to the next step.  If the conclusion is oppostie, we could
> even revert the previous changes.  It would be great if we could make it driven
> by data.
> 
>>
>> Regarding the MAINTAINERS patch: I listed myself for the new files, but did
>> not add SJ as a reviewer yet, since he mentioned limited bandwidth for Rust
>> work in that earlier discussion.  The existing DAMON entry already covers
>> samples/damon/, so the sample reaches him regardless; adding him to the
>> RUST [DAMON] entry would only additionally route future changes to
>> rust/kernel/damon.rs his way.  Happy to add the R: line if he wants it, or
>> leave it out if he prefers.
> 
> I think I should at least review the patches.  Also I feel I am responsible to
> the maintenance of the code.
> 
> We are extending DAMON to work for not only data access but general data
> attributes.  I'm also planning to refactor DAMON API quite a lot in near
> future.  Some interfaces will be added and removed.  DAMON API callers
> including sample modules would also need to be changed a lot.  If we make the
> Rust sample module with the current API, we may need to make changes not only
> in C but also Rust parts.  I concern if it can introduce more breakages that
> require unnecessarily long time to fix.  Among all, my lack of Rust
> understanding is a big concern.
> 
> I understand this patch series is a kind of experiment rather than for a real
> use case that has a hard deadline.  If I'm not incorrect, I feel like this
> might not be the best time to start the experiment.  Could we wait until
> fundamental parts including module parameters support in Rust and ongoing DAMON
> reconstruction, or my learning of Rust are done and stabilized?

Yes.  I will park the patches and restart once both are true:

1. Rust supports writable/sysfs-backed module parameters.
2. the DAMON API reconstruction has settled enough that wrappers can
   target the new interfaces directly.

Meanwhile I will keep working on DAMON in C as usual.

Enjoy the training day, and good luck with the Rust learning.

Thanks,
Enze

<...>