---
title: "Lang/RfL meeting 2024-08-28"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2024-08-28
discussion: https://rust-lang.zulipchat.com/#narrow/stream/425075-rust-for-linux/topic/meeting.202024-08-27
url: https://hackmd.io/1ccIZabpSfqe-w463Av4PQ
---

# Discussion

People: TC, nikomatsakis, Josh, Miguel, Alicy Ryhl, Andreas Hindborg, Gary Guo, Benno Lossin, Boqun Feng, tmandry, Xiang

https://rust-lang.github.io/rust-project-goals/2024h2/rfl_stable.html

https://github.com/nikomatsakis/rfcs/blob/rfl-project-goal/text/0000-rust-for-linux-project-goal-2024h2.md#ownership-and-other-resources

[Tracking issue](https://github.com/rust-lang/rust-project-goals/issues/116)

## Arbitrary self types v2 (@adetaylor)

https://github.com/rust-lang/rust/issues/44874

[Implementation in progress.](https://github.com/rust-lang/rust/issues/44874#issuecomment-2314739657)

In [this comment](https://github.com/rust-lang/rust/issues/44874#issuecomment-2292369151), adetaylor suggested that we want this style of code to work...

impl SomeType {
  fn method2<const ID: u64>(self: ListArc<Self, ID>) {}
}

...I think you do this, right Alice?

Alice: in practice I think we always hard-code the `ID`.

NM: OK, great, I think we will wind up accepting this code, but in case we wind up ruling it out, it would be good to know.

JT: It may be an easier restriction to prohibit generic parameters anywhere in the self type.

NM: It may be easier to explain but not necessarily implement.

Alice: I'll double check but I think it'd be ok.

## Derive smart pointer (@Darksonn)

Implementation proceeding but not yet complete. Enough to be useful, some cosmetic things still need to be changed. For example, `#[pointee]` is required even if there's one generic (versus it being a default).

Pinning work landed: https://github.com/rust-lang/rust/pull/125048

Next steps:
* PR https://github.com/rust-lang/rust/pull/129467 needs to be merged before the demo will work.
* Decide on the name for derive-smart-ptr (https://github.com/rust-lang/rust/issues/129104).

## asm_goto (@nbdd0121, @Darksonn)

We are using it for tracepoints and that usage is being upstreamed.

It would be useful if there was a way to return values, e.g.,

It'd be useful for asm-goto to be able to return a value so we can

asm!("...", foo = label { true }, fallthrough { false })

instead of

{'bar: { asm!("...", foo = label { break 'bar true; }); false }}

Current usage looks like this: (plus hacks to deduplicate asm between Rust and C)

/// arm64 implementation of arch_static_branch
#[macro_export]
#[cfg(target_arch = "aarch64")]
macro_rules! arch_static_branch {
    ($key:path, $keytyp:ty, $field:ident, $branch:expr) => {'my_label: {
        core::arch::asm!(
            r#"
            1: nop

            .pushsection __jump_table,  "aw"
            .align 3
            .long 1b - ., {0} - .
            .quad {1} + {2} + {3} - .
            .popsection
            "#,
            label {
                break 'my_label true;
            },
            sym $key,
            const ::core::mem::offset_of!($keytyp, $field),
            const $crate::arch::bool_to_int($branch),
        );

        break 'my_label false;
    }};
}

Challenge: the asm-goto block will be allowed to do unsafe things, forcing into a pattern where we want to return a boolean and branch on that (which in turn requires the analyzer to handle it).

Maybe we need a language construct for "safe"? Or just make the label blocks be safe always?

Josh: that might be confusing?

Tyler: maybe but not that hard to understand, right?

Gary: yes, though the C code is also returning true/false, might be easier. Not too much value of having an arbitrary block, this is custom control flow.

nikomatsakis: nonetheless, it seems better to me for other users.

josh: maybe allow `label unsafe {...}` so you don't need rightward drift.

josh: can you skim prospective or actual usages within RFL to see if there are a lot of cases where people immediately do unsafe within the branches?

**ACTION ITEM:** Josh to write up the proposal to have safe block bodies and post it somewhere.

## Extended offset_of syntax (@dingxiangfei2009)

With the merging of https://github.com/rust-lang/rust/pull/128284, this feature is now stable-on-nightly. :tada:

## RFL on Rust CI (@Kobzol)

Done but still waiting on policy documentation.

https://rustc-dev-guide.rust-lang.org/tests/rust-for-linux.html#what-to-do-in-case-of-failure

There was a case of intentional breakage. We got pinged, RFL gave a new hash, PR got merged.

Discussion:

https://github.com/rust-lang/rust/pull/129416

People seemed to think that it was their job to patch the kernel and didn't know about the instructions.

So what can we do to make this clearer?

Options:

* Include the link to the policy in the message
* Include some text like (non-normative sketch) "If this breakage is intentional, write `@rustbot ping rfl` so that the RfL users can be made aware of it. Don't worry, you don't need to patch the Linux kernel yourself, and you don't need to block this PR on fixing anything here; this is informational."

Other steps:

* Post an Inside Rust blog post
* Send an email to all@

Niko to follow up on this.

## Pointers to static in constants (@nikomatsakis)

[Stabilization report](https://github.com/rust-lang/rust/issues/128183) is now in FCP.

Help wanted: someone to author the [stabilization PR](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr). Note that no stabilization report is required.

Xiang Fei Ding can take it.

## Sanitizers supported only when another flag is passed

https://github.com/rust-lang/rust/pull/128348

This PR can actually move forward since tmandry delegated it.

Xiang is finishing up some things here and will then merge it.

Also https://github.com/rust-lang/rust/pull/129316 for Fuchsia and RISC-V platforms

Need to stabilize:

* The `-Zfixed-x18` flag
* The sanitizer itself

Next steps:

* Add `-Cfixed-x18` with `-Zunstable-options`
* We can keep the `-Zfixed-x18` for now, it's working back to 1.80, but is there much value. Maybe.
* Maybe `-Zunstable=flag1,flag2` or just `-Zunstable=*`
* if somebody wants to implement it
* Write up a stabilization report and open an issue

## Rust terminology in non-Rust Linux kernel patches

For people's interest; this seems like a notable positive cultural impact of Rust on the Linux kernel.

https://lore.kernel.org/linux-fsdevel/20240807-ostbahnhof-kaltfront-0f4476fd7587@brauner/T/

## KABI

https://lore.kernel.org/rust-for-linux/[e-mail]/

  struct struct1 {
    long a;
    long __kabi_reserved_0; /* reserved for future use */
  };
  struct struct1 exported;

  struct struct1 {
    long a;
    union {
      long __kabi_reserved_0;
      struct {
          int b;
          int v;
      };
    };

    #[repr(C)]
    pub union KAbiReserved<T, R> {
        value: T,
        _reserved: R,
    }

    impl<T, R> Drop for KAbiReserved<T, R> {
        fn drop(&mut self) {
            let val = &mut **self;
            unsafe { ptr::drop_in_place(val) };
        }
    }

    impl<T, R> Deref for KAbiReserved<T, R> {
        type Target = T;

        fn deref(&self) -> &Self::Target {
            unsafe { &self.value }
        }
    }

    impl<T, R> DerefMut for KAbiReserved<T, R> {
        fn deref_mut(&mut self) -> &mut Self::Target {
            unsafe { &mut self.value }
        }
    }

    impl<T, R> KAbiReserved<T, R> {
        pub fn new(value: T) -> Self {
            // we want to ensure that people don't accidentally use a bigger type.
            build_assert!(size_of::<R>() >= size_of::<T>());
            Self { value }
        }

        pub fn into_value(self) -> T {
            unsafe { self.value }
        }
}

NM: what about

#[repr(size=64)]

which errors if the value is too large?

Benno: how would that be represented in DWARF?

NM: Not sure! Gin up something... or make an attribute on a field... tl;dr it seems like something we could try and say directly.

## TYLER'S MYSTERY TOPIC

https://www.zdnet.com/article/linus-torvalds-talks-ai-rust-adoption-and-why-the-linux-kernel-is-the-only-thing-that-matters/

https://lore.kernel.org/rust-for-linux/[e-mail]/