Safe embedded code is state of the art [LWN.net]

Safe embedded code is state of the art

Posted Aug 14, 2024 18:56 UTC (Wed) by mb (subscriber, #50428)
Parent article: Standards for use of unsafe Rust in the kernel

>But, IMHO, we shouldn't treat Rust drivers as some unprivileged entity, they're also kernel code, after all

I would be surprised if drivers needed much unsafe code.

It is possible to write embedded Rust code for most needs without any unsafe blocks.
The unsafe blocks are hidden down in the pac and hal crates.

In the long term I would forbid unsafe code in most drivers.

to post comments

Safe embedded code is state of the art

Posted Aug 15, 2024 14:10 UTC (Thu) by DanilaBerezin (guest, #168271) [Link] (14 responses)

I don't think this is a great idea. This would definitely fall under the category of design decisions that work great until it doesn't, and then everything becomes a nightmare very quickly.

Banning unsafe in Rust for Linux device drivers

Posted Aug 15, 2024 14:29 UTC (Thu) by farnz (subscriber, #17727) [Link] (11 responses)

I don't see a ban on unsafe as being something imposed - there will not be a decree saying that "unsafe in drivers is not allowed", or a #[deny(unsafe_code)] equivalent enforced on drivers. Rather, the decree will be "don't use unsafe when there's a suitable safe abstraction you can use at no performance cost", and in the long run, this will be equivalent to a complete ban on unsafe code, since there will always be a safe abstraction you can use.

Banning unsafe in Rust for Linux device drivers

Posted Aug 15, 2024 15:05 UTC (Thu) by corbet (editor, #1) [Link] (10 responses)

The plan has always been to make it possible to write drivers without the need for unsafe. Surely there will be exceptions, but I expect things will get to the point where its use will be something that will stand out in review.

Banning unsafe in Rust for Linux device drivers

Posted Aug 15, 2024 16:51 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

> The plan has always been to make it possible to write drivers with the need for unsafe.

"With" or "without"?

Banning unsafe in Rust for Linux device drivers

Posted Aug 15, 2024 16:52 UTC (Thu) by corbet (editor, #1) [Link] (8 responses)

Yes, without; I'll fix the comment.

Banning unsafe in Rust for Linux device drivers

Posted Aug 16, 2024 10:01 UTC (Fri) by intelfx (subscriber, #130118) [Link] (7 responses)

> I'll fix the comment

We all want this superpower! :-)

Banning unsafe in Rust for Linux device drivers

Posted Aug 16, 2024 11:37 UTC (Fri) by daroc (editor, #160859) [Link] (6 responses)

~~Come write articles for us~~. I think the problem is that while the vast majority of people would use the power for good, letting people edit their comments makes moderation harder for us, since people could say something that goes against the rules and then change it before we saw it to cause confusion. Ideally, this would be solved by improving the moderation interface (and the database schema), but it isn't a trivial change. I've been mulling over potential changes.

Banning unsafe in Rust for Linux device drivers

Posted Aug 16, 2024 11:41 UTC (Fri) by mb (subscriber, #50428) [Link] (2 responses)

I like the github-style approach to that where you can edit at any time, but the edit history and the old versions are visible as well. (Can you delete history on github? I'm not sure right now. But LWN could disallow history deletion).

Banning unsafe in Rust for Linux device drivers

Posted Aug 16, 2024 22:07 UTC (Fri) by rc00 (guest, #164740) [Link]

> Can you delete history on github?

Yes.

Banning unsafe in Rust for Linux device drivers

Posted Aug 18, 2024 1:41 UTC (Sun) by KJ7RRV (subscriber, #153595) [Link]

This gave me an idea: would it be feasible to actually store article and comment content in a Git repository? That way, the site could just expose an interface to get a comment file's history.

Banning unsafe in Rust for Linux device drivers

Posted Aug 16, 2024 23:10 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

I don't really make much use of its power at work, but aiui, Slack allows edits for a *short* time.

So you might have a bit of a pain with moderation, but if you only allowed editing within, say, five minutes of the original post, then it balances your need to moderate with a poster's desire to correct something. After all, I expect most people spot their mistakes as they click "post" :-)

Cheers,
Wol

Banning unsafe in Rust for Linux device drivers

Posted Aug 21, 2024 20:25 UTC (Wed) by riking (subscriber, #95706) [Link]

You need to pair this with delaying email notifications until just after the edit period has expired.

Banning unsafe in Rust for Linux device drivers

Posted Aug 31, 2024 11:22 UTC (Sat) by sammythesnake (guest, #17693) [Link]

Reddit has a handy relative of this (though I don't think history is visible(?)) Edits are noted with something like "last edited at [time]" unless made within some small grace period after the initial post, because:

> most people spot their mistakes as they click "post" :-)

This is *absolutely* the case for the overwhelming majority of edits I'd like to make to *my* posts/comments :-/

Safe embedded code is state of the art

Posted Aug 15, 2024 14:32 UTC (Thu) by mb (subscriber, #50428) [Link] (1 responses)

Well, in embedded code it does work.
Why are kernel drivers any more special than that?

In my experience it is always possible to find a safe abstraction that makes sense instead of coding unsafe everywhere.

(And I deliberately said *most* drivers)

Safe embedded code is state of the art

Posted Aug 15, 2024 15:47 UTC (Thu) by DanilaBerezin (guest, #168271) [Link]

> (And I deliberately said *most* drivers)

Yes you're right. I glossed over that part.