Notes from 2021-04-24 call

* Notes from 2021-04-24 call
@ 2021-04-24 21:08 Geoffrey Thomas
  2021-04-25  7:39 ` Fabio Aiuto
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Geoffrey Thomas @ 2021-04-24 21:08 UTC (permalink / raw)
  To: rust-for-linux

Here's what I remember, please let me know if I misssed anything!

Meeting infrastructure and timing
===

We've been offered the use of LWN's BigBlueButton server if we want to 
switch to that instead of Google Meet. It seems like a good choice but 
there weren't a lot of very strong opinions either way.

Also, there were a good number of attendees who were interested in this 
work on behalf of their day job, so we might want to have a meeting on a 
weekday. We might also want to find a time that works better for Asia time 
zones, or alternate between the two times.

(The meeting also went two hours long - in my opinion we should just plan 
on that for the future, there's plenty of stuff to discuss. :) )

GitHub Actions
===

GitHub is no longer running Actions (their CI service) for new 
contributors to prevent abuse:

https://github.blog/2021-04-22-github-actions-update-helping-maintainers-combat-bad-actors/

It also seems like some existing contributors are being categorized as 
"new contributors" by GitHub. If CI isn't running for you, just ask (here 
or GitHub) and someone will add you.

panic and doesn't-panic annotations
===

We should make sure that any Rust code that (for now) intentionally calls 
panic!() or equivalent (.unwrap(), etc.) has a comment explaining that it 
panics under certain conditions, so we can find it and clean it up later, 
e.g. when we have support for fallible allocations.

Also, we should make sure that any code that panics that expects not to 
actually panic in practice (e.g., we can convince ourselves that a certain 
unwrap will always succeeds, but we can't fix the types) has a comment 
explaning why we believe it's fine.

There's a discussion here: 
https://github.com/Rust-for-Linux/linux/pull/207#discussion_r619298277

(Hm, probably we should have some brief coding-style docs on this?)

BUG vs. OOPS
===

There's a desire to avoid increasing the use of BUG and exposing BUG to 
Rust code via the panic mechanism. It seems this was just a 
misunderstanding by me/Alex in the initial code - we were expecting that a 
panic should just crash the current thread but should not crash the entire 
kernel. The right thing to bind to is OOPS. On the C side, dereferencing 
an invalid pointer gets you an OOPS, not a BUG, so Rust should do the same 
thing in the same scenario (but _before_ actually dereferencing the 
pointer :) ). This should be a quick change, it doesn't seem like there's 
a particular reason we needed BUG.

liballoc and fallible allocations
===

Rust's "liballoc" is the portion of the standard library that wraps the 
system allocator (e.g. malloc in normal userspace) and provides various 
container types, e.g. Box for plain allocated objects and Vec for 
growable allocated vectors/arrays.

One of the (very understandable!) major points of concern with the initial 
RFC was that the liballoc types panic on allocation failure. This is 
generally fine in userspace (especially if your OS has overcommit) but not 
for the kernel. The upstream Rust community is interested in extending 
liballoc so that it can report allocation failure through a normal Result 
type ("fallible allocations"), but there are some open design questions.

Miguel proposed maintaining a temporary in-tree fork of Rust's liballoc 
that has only fallible allocations. The strong advantage of that is that 
it allows us to iterate on the design and provide feedback to upstream 
Rust, without running into trouble with the stability process. The 
downside is that all code in the kernel tree is generally expected to be 
open to changes by kernel developers (with a few exceptions, e.g., ACPICA) 
and we want to make sure this is indeed a temporary fork.

The current best plan seems to be to say that, as maintainers, we'll 
accept minor changes that don't make big changes to the APIs. If people 
want to add Linux-specific changes that won't necessarily get accepted in 
upstream liballoc, that's okay, provided that it doesn't impact our 
ability to drop the fork later.

We discussed whether we want to set up CI to test that you can replace the 
in-tree version with the latest upstream liballoc, with unstable features 
enabled, and builds/tests still work. It's an interesting idea, but the 
difficulty is we do actually want to introduce new APIs or change some 
return types to Result, so we can't use upstream liballoc yet. (Maybe once 
we get a draft design into upstream liballoc, we can come back to this.)

There's some work in upstream liballoc to make it handle environments that 
cannot panic on allocation failure (not just us, but also embedded 
systems). Here's a work-in-progress PR to disable all methods that could 
panic on allocation failure:

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

Also, it seems like getting a bunch of try_* methods (try_new, try_push, 
etc.) would be acceptable upstream.

GFP flags
===

Another challenge with allocation is that the kernel allocator takes flags 
indicating which context an allocation is in (e.g., whether it can block, 
cause filesystem activity, etc. to make some room), and the standard Rust 
APIs don't really give us a way to specify that.

For things like "am I running in interrupt context and therefore cannot 
block," we really want to figure out how to make this automatic in some 
manner, because it's easy to get wrong in C already.

For "allocate memory from a specific region of physical memory for device 
drivers" (e.g., GFP_DMA32), it doesn't seem like there's a lot of sense in 
allocating the richer collection types - your device hardware probably 
isn't going to know what to do with a BTreeMap. We think it will be enough 
to have code request raw pages and, if needed, use unsafe 
{from_raw_parts(...)} to get an object they can work with safely.

Kernel Summit and Plumbers
===

The Kernel Summit and the Linux Plumbers Conference are coming up this 
summer, possibly in Dublin, possibly virtual. Both of these seem like a 
good place to work out concerns that kernel developers may have. We should 
probably propose something for both.

I believe Nick and Josh will submit something for Kernel Summit, which 
wants submissions fairly soon. For Plumbers, we should submit something to 
the microconferences (which are for discussions, as opposed to the 
refereed track which is for presentations), and the microconference 
submissions will open later.

Safety, terminology, benefits
===

There was a good bit of discussion that the "safety" value proposition of 
Rust may not be totally clear to people who have been writing C for a very 
long time and for whom Rust is new - to some extent, the entire idea that 
you can write serious systems code in a "safe" language is the innovation 
of Rust, and people might be thinking of Rust as a langauge that's more in 
the space of Java/Python/etc. in order to be safe.

There was also a mention that the term "RAII" was new to at least one 
experienced kernel developer, and and a mention that the idea of 
"zero-cost abstractions" was surprising to people.

It would very likely be worth us having some documentation explaining how 
these things work - especially what we mean by "safety" and how one could 
possibly write device drivers (which need to access raw hardware) in a 
"safe" language.

Sample drivers
===

Along those lines, a priority, but not as high as sorting out our liballoc 
story, is having more sample drivers.

One idea that was floated was to port the "scull" driver from the _Linux 
Device Drivers_ book to Rust.

We've also been asked to provide some sample drivers - but it seems 
worthwhile to put a little disclaimer that if we're porting existing C 
drivers to Rust, it's as a demonstration to see what it would look like in 
Rust, and not a proposal to immediately mass-rewrite everything in Rust. 
Also, it was mentioned that if you're rewriting an existing C driver, you 
need to keep the copyright statement on the existing driver.

Samantha Miller, the lead author of a neat-looking academic project to 
implement some filesystems in Rust 
(https://gitlab.cs.washington.edu/sm237/bento), was on the call and and 
expressed interest in using the Rust support that's being proposed for 
upstream. Some of these filesystems might be starting points for examples 
of Rust drivers to include upstream.

Other notes
===

I remember someone mentioned something about control flow graphs and 
having the compiler automatically do something, but I forget the details - 
was this about tracking panics? or tracking GFP flags?

-- 
Geoffrey Thomas
https://ldpreload.com
geofft@ldpreload.com

^ permalink raw reply	[flat|nested] 4+ messages in thread