* 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
* Re: Notes from 2021-04-24 call
2021-04-24 21:08 Notes from 2021-04-24 call Geoffrey Thomas
@ 2021-04-25 7:39 ` Fabio Aiuto
2021-04-26 6:36 ` Notes from 2021-04-24 call, location / venue next call Geert Stappers
2021-04-27 0:34 ` Notes from 2021-04-24 call Miguel Ojeda
2 siblings, 0 replies; 4+ messages in thread
From: Fabio Aiuto @ 2021-04-25 7:39 UTC (permalink / raw)
To: Geoffrey Thomas; +Cc: rust-for-linux
Thank you Thomas for this work,
fabio.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Notes from 2021-04-24 call, location / venue next call
2021-04-24 21:08 Notes from 2021-04-24 call Geoffrey Thomas
2021-04-25 7:39 ` Fabio Aiuto
@ 2021-04-26 6:36 ` Geert Stappers
2021-04-27 0:34 ` Notes from 2021-04-24 call Miguel Ojeda
2 siblings, 0 replies; 4+ messages in thread
From: Geert Stappers @ 2021-04-26 6:36 UTC (permalink / raw)
To: rust-for-linux
On Sat, Apr 24, 2021 at 05:08:04PM -0400, Geoffrey Thomas wrote:
> Here's what I remember, please let me know if I misssed anything!
> Meeting infrastructure
> ===
>
> We've been offered the use of LWN's BigBlueButton server if we want to
> switch to that instead of Google Meet.
Please make that switch.
> It seems like a good choice
> but there weren't a lot of very strong opinions either way.
Here, this mailinglist, we can _all_ express opinion on it.
Google Meet did again insist on an account. The no login succes
of last week during a test seemed to be a fluke.
Inside (that single session) was my microphone not detected.
My encounters with BigBlueButton are much better
* Microphone being detected
* No account hassle
> 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. :) )
>
Groeten
Geert Stappers
--
Silence is hard to parse
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Notes from 2021-04-24 call
2021-04-24 21:08 Notes from 2021-04-24 call Geoffrey Thomas
2021-04-25 7:39 ` Fabio Aiuto
2021-04-26 6:36 ` Notes from 2021-04-24 call, location / venue next call Geert Stappers
@ 2021-04-27 0:34 ` Miguel Ojeda
2 siblings, 0 replies; 4+ messages in thread
From: Miguel Ojeda @ 2021-04-27 0:34 UTC (permalink / raw)
To: Geoffrey Thomas; +Cc: rust-for-linux
Hi Geoffrey,
Thanks a lot for writing the notes!
On Sat, Apr 24, 2021 at 11:08 PM Geoffrey Thomas <geofft@ldpreload.com> wrote:
>
> (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. :) )
I will send an email about an update on this :)
> (Hm, probably we should have some brief coding-style docs on this?)
+1 I will be updating it alongside other bits in my next doc round.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-04-27 0:34 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-24 21:08 Notes from 2021-04-24 call Geoffrey Thomas
2021-04-25 7:39 ` Fabio Aiuto
2021-04-26 6:36 ` Notes from 2021-04-24 call, location / venue next call Geert Stappers
2021-04-27 0:34 ` Notes from 2021-04-24 call Miguel Ojeda
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.