REWG questions / discussion with Rust Project

[BartMassey]

We have some upcoming opportunities to ask questions and make requests with the Rust Project. Pain points in particular. Let's organize here for that.

[BartMassey]

We've had discussions around the usability of address 0, inspired by #issues/908 . Would be nice to clarify in what contexts address 0 and its pointers/refs can / should be legitimately used.

[BartMassey]

My particular question is whether raw pointers to address 0 can be derefed without UB, and if not why not? Since these derefs aren't being checked, it seems to me like a good idea to give them the expected semantics rather than no semantics — is very occasionally useful in embedded, and seems harmless. Maybe there's some LLVM issue here, or some Rust repr issue I'm missing?

[BartMassey]

Also discussed with Josh previously the possibility of stabilizing &raw const self and &raw mut self sooner rather than later. Would be syntactic, but a huge convenience boost I think? How much would people here be excited by this?

[BartMassey]

We should discuss register reads and writes in the context of https://ferrous-systems.com/blog/hardware-access-rust/ , maybe? The article provides a good starting point for that discussion.

[jonathanpallant]

https://lokathor.github.io/volatile/ is worth reviewing - I understand that having volatile operations rather than volatile types was a deliberate choice.

[jonathanpallant]

As noted in the blog, what I would really like is some method to go from 'pointer to struct' to 'pointer to field in struct' without doing:

let fifo_ptr = unsafe { &raw mut (*uart_ptr).fifo };

That's very difficult to teach. Something like this would be much nicer:

let fifo_ptr = uart_uart.fifo;

(I don't know that it needs to be unsafe for someone to take a pointer to a field given a pointer to a structure, but I'm happy for some compiler people to convince me it should be)

[BartMassey]

@jonathanpallant Thanks much for the link to the volatile blog post.

A volatile operation may not modify any other memory accessible by the module being compiled.

Okay… okay… so we can’t use a volatile access to change the memory in the “normal memory” parts of the program.

To go back to a previous example: we can use volatile to tell a DMA unit to copy from our buffer into another place outside the address space, but we can’t use volatile to copy to our buffer, because that would modify memory accessible from the module being compiled.

Am I misreading this, or is all my code broken? I'm probably just being dumb again: someone please ELI5 how to do DMA reads safely without explicit asm? The next paragraphs in the block strongly imply I can't, but if so that's… not ok. Maybe something has been added since the blog post was written?

[BartMassey]

Related question: is UnsafeCell relevant? I kind of thought it was, but looking closely at it now I think it isn't.

[andre-richter]

we can use volatile to tell a DMA unit to copy from our buffer into another place outside the address space, but we can’t use volatile to copy to our buffer

„by the module being compiled“ is the important part here I‘d say. If the buffer you want your DMA to read into is not part of .text, .data, .bss, .you_name_it, it should be fine to kick off the DMA read from Rust code with a volatile operation.

Carve out an address range in your memory/DRAM outside of where your program gets loaded, and have a custom allocator you wrote hand subranges out for use as DMA buffers?
But the question is if its useful for your program to have them in a pointed-to location only.

Maybe a practical hack would be an empty asm block with a memory clobber right after the volatile operation that kicks the DMA engine?

[BartMassey]

A perennial problem for me is how to make trait objects available globally without a heap, so that they can be mutably shared with interrupt handlers. The issue arises because of the RE practice of giving peripheral instances unique types: one wants to write a library that stores a Pin or a peripheral or something without regard to which one it is, up to obeying a trait that makes them all equivalent.

So for example my fantasy would be to be able to write something vaguely like

static mut ADC: Option<Adc<T: AdcTrait>> = None;

This is obviously wrong and maybe even horrible, but communicates the idea I think?

Maybe there's some way to get something like this that I don't know about? All the options I've explored are grim at best.

[kevinmehall]

type_alias_impl_trait seems to be the plan for this, and it already works on Nightly:

type Adc = impl AdcTrait;

static mut ADC: Option<Adc> = None;

#[define_opaque(Adc)]
fn main() {
    let adc = unsafe { &mut *&raw mut ADC };
    *adc = Some(SomeAdc::new());
}

The related impl_trait_in_assoc_type can also do this with much uglier syntax for this use case, and it seemed like it had some movement towards stabilization a year or two ago, but last I heard it seems like they're waiting for the new trait solver. Embassy has an optional feature to use this for putting un-nameable impl Future types in static tasks and my zeptos executor is nightly-only because it relies on it.