On Sun Sep 14, 2025 at 1:02 AM CEST, Joel Fernandes wrote: > On Sat, Sep 13, 2025 at 09:53:16PM +0200, Danilo Krummrich wrote: >> On Sat Sep 13, 2025 at 7:13 PM CEST, Joel Fernandes wrote: >> > On Sat, Sep 13, 2025 at 03:30:31PM +0200, Danilo Krummrich wrote: >> >> However, we should never do such things. If there's the necessity to do >> >> something like that, it indicates a design issue. >> >> >> >> In this case, there's no problem, we can use pin-init without any issues >> >> right >> >> away, and should do so. >> >> >> >> pin-init is going to be an essential part of *every* Rust driver given >> >> that a >> >> lot of the C infrastruture that we abstract requires pinned >> >> initialization, such >> >> as locks and other synchronization primitives. >> > >> > To be honest, the pinning concept seems like an after thought for such a >> > fundamental thing that we need, requiring additional macros, and bandaids >> > on >> > top of the language itself, to make it work for the kernel. I am not alone >> > in >> > that opinion. This should be first-class in a (systems) language, built >> > into >> > the language itself? I am talking about the whole pin initialization, >> > accessing fields dances, etc. >> >> Yes, that's exactly why people (Benno) are already working on making this a >> language feature (here's a first step in this direction [1]). >> >> Benno should have more details on this. >> >> [1] https://github.com/rust-lang/rust/pull/146307
That's the link to the implementation PR, if you know the internals of the compiler it sure is useful, but if not, only the first comment is :) > Ack, thanks for the pointer. I will study it further. I'd recommend looking at these links, as they talk more about the design & not the compiler implementation: * https://github.com/rust-lang/rust/issues/145383 * https://hackmd.io/@rust-lang-team/S1I1aEc_lx * https://rust-lang.github.io/rust-project-goals/2025h2/field-projections.html For pin specifically, there also is the pin-ergonomics effort: * https://github.com/rust-lang/rust/issues/130494 Which is less general than the field projections that I'm working on, but more specific to pin & tries to make it more compiler internal. Now for pinned initialization, Alice has a project goal & proposal: * https://rust-lang.github.io/rust-project-goals/2025h2/in-place-initialization.html * https://hackmd.io/%40aliceryhl/BJutRcPblx This proposal was heavily influenced by pin-init & we're actively working together with others from the Rust community in getting this to a language feature. It's a pretty complicated feature and people just worked around it before, which you can do when starting from the ground-up (similar to field projections). >> > Also I am concerned that overusage of pinning defeats a lot of >> > optimizations >> >> pin-init does the oposite it allows us to use a single memory allocation >> where >> otherwise you would need multiple. >> >> Can you please show some optimizations that can not be done in drivers due to >> pin-init for dynamic allocations? > > Aren't the vector resizing issues an example? The debugfs discussions for > example. You can't resize pinned vectors without boxing each element which is > suboptimal due to requiring additional allocations? Yes, but that's not really an optimization, is it? In the non-pinned case, the compiler wouldn't remove the allocation. You can select less efficient algorithms, since the objects aren't allowed to move, but that same restriction also applies in C. --- Cheers, Benno
