►
Description
Rust for Linux is a project that aims to bring Rust support to the Linux kernel as a first-class language. This means providing support for writing kernel modules in Rust, such as drivers or filesystems, with as little unsafe code as possible.
This session will briefly explain how the Rust support works in the kernel and will give an update on the status of the project, as well as what is planned for the near future. It will also show a wishlist of Rust features that could help the project.
About Miguel
Miguel is a software engineer that maintains the Rust for Linux effort, as well as the auxdisplay, compiler attributes, and clang-format trees. He also participates in the ISO C committee, with an interest in UB and memory-safety topics. Previously, Miguel was a Staff Member at CERN in the Beams department and a Fellow in the Physics department.
About Wedson
Wedson is a software engineer that maintains the Rust for Linux effort; he is currently part of the Android platform security team at Google. For the past 19+ years, he has worked on kernels, bootloaders, hypervisors, etc. at Google, Facebook, and Microsoft.
Thanks to Microsoft for their Support!
Rust Linz:
https://rust-linz.at
https://sessionize.com/rust-linz
https://twitter.com/rustlinz
A
A
A
The
patches
that
we
send
to
the
kernel
many
lists
there
is
a
lot
of
people
that
have
been
contributing
and
we
hope
more
and
more
people
contribute
to
the
project
yeah
and
with
that,
so
let
me
introduce
crust
and
the
kernel.
So
in
the
in
the
patches
that
we
sent
to
the
kernel
middle
east,
we
we
said
we
wanted
to
reduce
rust
as
a
second
language
in
the
kernel
right
and
some
people
of
course
say
that
there
are
a
lot
of
languages
which
is
completely
right.
A
A
B
A
A
B
A
A
B
A
For
for
for,
for
parts
of
the
final
binary,
the
the
binary
that
you
run
when
you
put
your
reno's
current
right
now,
you
see
on
the.
If
you
can
go
back
please,
what's
on
the
moment,
you
see
that
it's
only
105,
but
if
we
got
into
the
kernel
and
people
start
really
using
maintainers
and
developers
are
really
using
and
companies
the
rust
it
will
grow
to.
B
A
Basically,
to
the
same
level
as
c,
maybe
not
as
much,
but
what
we
mean
is
that
it
will
be
used.
There
is
one,
for
example,
this
one
file
per
module
driver
or
several
files,
so
it
will
roll
and
grow
and
grow,
and
that's
what
we
mean
by
the
second
law,
which
is
the
second
language
that
is
general
purpose.
A
B
A
To
this
is
probably
because
you
you
like,
as
well
as
we
like
a
decreased
chance
of
memory,
safety
bugs
we
say,
decreased
chance
because,
yes
in
safe
rust
in
principle
is
impossible,
but
we
use
unsafe
rust
and
there
is
always
a
possibility,
of
course,
of
bugs
in
the
in
the
core
or
other
primers.
For
example,
there.
A
B
A
We
hope
that
by
using
rust-
and
this
is
one
of
the
main
goals
that
we
want
to
achieve-
is
that
writing
drivers,
especially
at
least
in
the
beginning,
drivers
and
other
kernel
modules-
is
easy.
It's
easier
than
we
see,
you
don't
have
to
pay
as
much
attention
to
detail
with
respect
to,
for
example,
memory
safety
and
also
for
reviewers
of
that
code,
because
when
you
submit
some
code
to
the
to
the
government,
there
is
people
that
have
to
review
it.
A
B
A
So
it's
also
good
to
have
a
language
that
has
a
strong
typing,
etc,
so
that
refactoring
all
those
drivers
is
easy
in
the
future
and
also
another
goal
that
we
could
say
is
that
we
have
a
chance
by
using
a
new
language.
We
have
a
chance
to
not
fix,
but,
let's
say
improve
other
related
things.
For
example,
formatting
the
code
documenting
vendor
record
enforcing
some
convention
for
documentation,
writing.
A
Said
before
is
we
want
to
have
rash
drivers
in
the
left
side
of
the
of
the
of
the
slide.
We
want
to
write
drivers
in
rust
in
safe
routes
as
much
as
possible,
which
called
safe
attractions
and
the
sex
attractions.
They
basically
wrap
c
code
and
for
calling
the
c
apis
in
the
kernel.
We
are
just
not
safe.
It's
possible
that
in
the
future
we
may
instead
of
wrapping
c
c
code.
A
Currently
in
the
kernel,
it's
possible
that
if
rust
takes
off
it's
possible
that
we
may
even
write
our
own
say:
subsistence,
for
example,
in
in
the
last
site,
but
so
far
what
we
are
trying
to
do
is
wrap
the
c
apis
that
they
want
the
facilities
that
exist,
the
camera
already,
so
that
it
can
be
used
safely
from
rust.
So
we
are
not
trying
to
basically
rewrite
the
cut.
A
This
is
what
it
means,
and
the
forbidden
line
that
you
see
in
the
bottom
means
that
we
eventually
or
ideally
we
want
to
forbid
that
a
driver
or
driver
calls
directly.
They
see
apis.
It
may
call
and
save
apis
in
our
abstractions.
That's
fine,
but
we
want
to
avoid
that.
They
depend
directly
on
the
on
the
c
apis.
B
A
B
B
A
A
At
compile
side,
for
example,
for
changing
the
frequency
of
something
or
to
enable
a
driver
or
to
disable
a
driver
or
to
make
it
a
built-in
or
external
module,
etc.
So
that
system
is
k-config
and
all
these
two
together
basically
do
everything
right
now
in
the
kernel.
So
for
compiling
and
doing
all
this
to
make
everything
work,
we
are
using
the
same
build
system
as
the
as
the
as
the
kernel
does
right
now,
so
we
don't
use,
for
example,
cargo
and
cargo.
A
A
A
Into
the
linux
kernel
tree
a
subset
of
the
yellow
grid,
because
we
need
a
few
new
methods
and
perhaps
in
the
future
modification
we
have
to
see.
So
what
we
do
is
we
keep
it
in
sync
all
changes
with
with
upstream,
but
in
the
future.
Ideally,
we
will
be
able
to
use
alloc
the
vanilla
a
lot.
If
you
will
then
alloc
depends
sorry,
the
kernel
crate
depends
on
alloc,
we
use
a
lock.
We
also
have
a
built-in
crate,
which
is
to
substitute
the
compiler's
built-ins.
A
B
A
B
A
Thing
here
with
the
helpers
is
that
currently,
for
example,
we
we
write
all
the
helpers
manually
where
a
helper
is
not
it's,
not
the
header
that
we
use
from
the
from
the
kernel
that
binding
generates,
but
the
helpers
are
more
for,
for
example,
when
we
need
to
use
a
c
macro
that
is
sufficiently
complex,
that
binding
kind
of
generated
automatically
for
us,
for
example,
say
a
macro
that
declares
a
mod,
let's
say
so.
For
those
things
we
have
to
create
a
wrapper
function
and
see
that
then
binding
can
call
it.
A
A
So
far,
it's
experimental.
Still,
it's
not
meant
the
russian
force
we
have
is
not
meant
to
use
to
be
used
in
production,
just
not
just
because
we
use
unstable
features,
as
we
will
see
in
a
moment,
but
also
because
well
there
are
other
there
are.
There
are
many
things
that
we
have
to
take
care
of
details
and
details,
and
it
has
always
come
to
take
care,
but
even
if
it's
experimental,
it
works
and
it's
useful
already
to
work
on
right,
new
instructions
for
subsistence
and
other
things.
It's
also
useful
for
writing
drivers.
A
So
and
next
steps
on
on
what
we
are
doing,
first
of
all
for
the
infrastructure,
there
are
two
main
parts
of
what
normally
we
when
we
submit
the
patches
to
the
credibility.
We
talk
always
happy
about
two
parts.
One
is
the
infrastructure,
the
build
system
and
everything
else
that
has
to
go
into
making
this
work,
and
then
there
is
the
actual
rasco
that
is
probably
the
most
interesting
for
you.
A
A
B
B
A
Are
actually
used
in
production,
so
we
need
to
have
the
support
for
that
and
we
want
to
work
on
that.
Then
we
also
have
to
complete
the
architecture,
support,
perhaps
even
add
more
architecture.
We
have
a
few
of
them
as
examples
basically
and
then,
on
the
other
side,
the
attractions
and
drivers,
of
course,
more
and
more
facilities.
Basically,
this
means
wrapping
more
and
more
data
structures,
more
facilities
from
from
more
primitives
from
the
from
from
the
kernel
side,
for
example,
we
have
a.
B
A
B
A
Kernel
because
the
previous
church
lights
are
about
what
we
are
working
on
right.
In
order
to
accomplish
this,
which
is
the
main
goal
which
is
getting
into
a
kernel
so
that
people
can
start
actually
using
it
and
are
confident
that,
even
if
it
is
merged
as
experimental
as
an
experimental
feature,
at
least.
A
A
We
have
to
actually
contact
the
gpio
maintainers,
because
the
kernel,
as
you
may
know,
is
like
divided
in
many
many
sections
and
subsistence
of
subsystems,
and
there
are
maintainers
for
each
piece
for
each
of
these
species
and
we
don't
want.
We
cannot
really
be
experts
or
try
to
write
all
wrappers
and
have
knowledge
on
every
single
of
these
subsystems.
So
the
idea-
and
what
we
want
to
accomplish
is
that
key
maintainers
of
some
individual
sections
of
the
kernel
that
want
to
use
rust
and
that
they
want
to
use
it
as
early
as
possible.
A
Have
them
on
board.
Have
them
review
the
code,
understand
the
codeword
writing.
Even
if
we
write
a
code
in
the
beginning,
but
have
them
understand
and
support
us.
And
then,
if
the
support
becomes
non-experimental
at
some
point,
then
they
will
be
already
ready,
because
that's
that's
basically
the
main,
the
main
thing,
so
one
key
thing
is
getting
support
from
kernel
maintainers.
A
We
have
already
support
from
a
few
of
them,
but
we
are
looking
into
into
to
get
it
even
more
and
more
and
for
that
sub
or
a
second
thing
we
have
to
do
is
providing
learning
resources
documenting
things.
We
are
doing
as
much
as
possible
answering
the
question
from
antennas
from
other
developers,
etc,
so
that
they
are
confident
that
first,
this
works.
This
is
an
improvement
over
what
we
are
doing
in
c
and
yes,
basically
convincing.
If
you
will
everyone,
the
the
people.
A
A
A
We
know
we
have
work
with
rust,
but
we
are
not
experts
in
that
sense.
So,
basically,
we
have
been
using
rust
to
the
better
of
to
the
best
of
our
abilities,
and
we
have
found
some
things
that
we
would
like,
perhaps
to
to
not
improve
or
to
fix
that
perhaps
things
that
we
would
like
to
have
or
things
that
we
we
think
would
be
an
improvement
to
the
language
if
they
were
there
first
of
all.
A
A
A
A
This
is
fine
for
the
moment,
but
at
the
point
where
we
want
to
you
to
be
pissed,
we
use
in
production.
We
really
have
to
say
this
is
the
point
where
code
will
not
break
in
the
future,
at
least
not
in
a
major
way.
Let's
say
so.
These
are
the
unstable
features
I
keep
the
list
here.
The
ones
in
both
are
like
the
important
ones
that
currently.
B
A
Have
this
may
change,
but
yes,
as
you
see,
there
are
quite
a
few.
There
are
others
that
can
be
work
around
the
ones
that
are
not
involved,
maybe
work
around
or
not.
But
yes,
if
you
want
to
have
more
details,
go
to
the
list
or
to
the
doctor
I
described
and
then
just
to
start
a
bit
with
the
wishes.
This
is
an
easy
one
that
we
want
to
highlight,
which
is
having
unsafe
op
enhancing
fn.
A
In
rust,
as
you
probably
know
where
having
it
denied
means
that
the
functions
don't
have
an
implicit
block
in
them
anymore,
so
you
can
go.
The
language
would
change
from
writing,
for
example,
something
like
in
the
left
to
something
in
the
in
the
right
side.
We
think
this
is.
We
agree
with
making
it
a
hard
error,
because
we
think
the
language
should
be
like
this
by
default.
A
B
A
B
Thank
you
thank
you,
miguel
yeah,
so
so
so
now
we're
going
to
to,
as
miguel
described
in
the
beginning,
we're
going
to
switch
gears.
It's
going
to
be
a
little
bit
more
technical
with
more
code
and
some
diagrams
here.
So
we're
going
to
talk
about
pinning
and
the
reason
pinning
is
is
is
important
to
us
is-
is
that
in
a
lot
of
drivers,
in
fact,
some
some
real
production
drivers
that
that
we
convert
or
we
look
into
pinning
is-
is
the
one
source
of
unsafety
for
us.
B
So
so
really
what
what
we'd
like
to
see
is
is:
is
these
unsafe
requirements
like
the
need
for
these
unsafe
blocks
to
to
to
go
away
so
we're
going
into
some
of
the
reasons
why
they
needed
at
the
moment
so
before
we
go
into
that
a
little
bit
of
of
background
on
this
principle
that
that
that
we
follow
and
that
miguel
already
described
briefly
in
in
previous
slides.
But
the
principle
is
that
we
we
we
use
existing
c
kernel
code.
B
We
try
to
avoid
reinventing
the
wheel
when
we're
implementing
things
in
rust,
if
they're,
already
available
in
in
c
and
well.
The
the
main
reason
is
that
the
subsystems
are
currently
written
in
c,
so
we
do
have
to
interact
with
with
c
at
the
moment
anyway,
even
even
if
we
didn't
want
to
we
have
to,
because
that's
that's
that's
where
the
code
is
at
the
moment
most
of
this
seagull.
This
is,
is
battle
tested
in
production.
B
Another
reason
is
that,
and
in
fact
this,
this
last
reason
that
I
have
listed.
There
is
mostly
for
cases
when
we
already
have
a
rust
implementation
of
something,
and
we
also
have
a
c
implementation
in
the
kernel
and
in
in
most
cases
we
end
up
choosing
the
the
the
kernel
version
over
the
the
c
version,
and
in
most
cases
is
because
there
are
certain
choices
that
we
can
make
when,
when
we
are
writing
code-
and
these
choices
are,
in
some
cases,
difference
between
user
space
and
and
and
kernel
space
and
I'll.
B
B
What's
the
point
of
of
of
doing
rust
right,
it
would
be
no
better
and,
as
miguel
already
pointed
out
in
in
one
of
the
previous
slides
too,
what
we
are
doing
is
we
are
building
this.
This
safe
and
hopefully,
zero
cost
and
I'll
have
some
more
a
little
bit
more
to
say
about
the
the
zero
cost
here
abstractions
around
this
c
code
right.
B
So
so
what
what
we
are
doing
is
we
have
c
code
that
we
want
to
reuse,
but
we
abstract
it
away
in
in
a
safe
way
to
to
to
russ
code,
rust,
drivers
and,
and-
and
the
idea
is
that
will
benefit
from
from
from
this
from
the
50
properties
that
russ
offers
us
so
here's
here's
an
example
of
of
we
feel
is
a
successful
example
of
of
reusing
existing
c
code
in
in
in
the
current.
So
what
what
what
we
had
here?
B
The
options
is
in
rust.
We
have
arc
xtr
candidates
in
in
in
liberlock,
so
we
could.
We
could
use
it
if
we
wanted,
and
in
fact
we
when
we
started,
we,
we
were
using
this
and
we
have
a
a
competing
implementation
of
this
in
on
on
the
c
side
in
the
kernel
that
is
ref
count
t
okay,
they
are
slightly
different,
so
they
both
just
do
reference
counting
and
atomic
reference,
counting,
meaning
that
we
use
atomics
to
increment
and
decrement
ref
counts,
so
they
can
happen
concurrently,
but
the
implementation
is
slightly
different.
B
The
the
c
version
has
less
features.
It
doesn't
have
like
weak
references,
for
example,
so
they
actually,
the
implementation
uses
just
one
32-bit
integer
of
of
extra
space.
That
needs
to
be
allocated
when
you
allocate
an
object,
whereas
the
rust
version
uses
two
words,
but
this
is
not
all
all
that
that
relevant.
I
mean
basic
differences,
but
the
most
relevant
difference
for
us,
and
this
is
what
drove
us
to
to
to
to
replacing
arc
removing
arc,
basically
from
our,
so
we
never
use
arc
anymore.
We
use
this.
B
This
other
thing
that
we
implemented
is
the
behavior
when,
when
these
this
counts
overflow
right.
So
if
you
actually
have
a
bug
in
in
in
in
the
code
where
you
you
forget
to
decrement
the
ref
count
in
some
in
some
code
pads-
and
in
fact
this
is
harder
to
to
to
get
to
with
breasts,
but
it
can
happen
right,
you
can
actually
forget
a
a
ref
counted
object
and
then
the
drop
doesn't
get
called,
and
so
the
decrement
never
happens.
B
This
could
happen
in
in
rust
too,
and
it's
not
unsafe.
For
this
to
happen,
however,
this
can
be
a
source
of
unsafety
if,
if
attackers
notice
that
that
this
is
happening
and
they
actually
trigger
the
repeated
leak
such
that
eventually,
we
overflow
this
count
right
and
then
we
overflow
this
count.
If
nothing
is
done,
what
happens
is
that
the
account
goes
to
zero
right?
B
We
think
that,
oh
actually
it
goes
to
one
eventually
and
then
one
successful
decrement
brings
it
back
to
zero,
and
then
we
think
that
we
need
to
feed,
and
then
we
free
it,
and
now
we
have
a
dangly
point.
Potentially
several
dangling
points
is
actually
the
same,
pointing
to
the
same
place
that
has
been
freed,
but
in
several
places
potentially
anyway.
So
there's
a
security
issue
there
and
a
safety
issue
there,
memory
safety
issue
there.
B
So
what
we
have
to
do
is
we
have
to
realize
when
these
overflows
are
happening,
and
you
have
to
react
to
that.
The
what
rust
does
really
is
is
aborts.
It
aborts
the
process.
It
stops
running
the
process.
It's
not
a
panic,
it's
on
a
board
right,
which
makes
sense
in
user
space,
right,
you're,
running
a
process
and
use
some
inconsistent
state,
and
we
just
want
to
kill
it
and
have
it
restarted.
If
it's
a
service,
for
example,
it
makes
sense
in
user
space.
B
But
if
it's
in
the
kernel,
what
we're
doing
is
we're
bringing
down
the
whole
kernel.
The
whole
machine
is
coming
down.
Our
virtual
machine
is
coming
down
because
of
this,
so
we'd
like
to
to
avoid
that
and
the
the
what
what
the
kernel
does.
Is
it
saturates
the
count
right?
So
when
you
see
it's
about
to
overflow,
we
put
it
at
some
some
some
value,
and
then
we
leave
it
at
that
value.
So
we
never
free
the
memory.
B
B
Features
but
anyway,
since
since
we
were,
we
were
implementing
a
new
version
of
that
we
made
some
some
slight
changes
too.
For
example,
we
removed
cat
mute,
which
means
that
it's
it's
pinned
automatically.
So
when
you
allocate
some
memory
and
it's
ref
counted
it
spins
now,
why
why
why
that
does
the
spinning
matters
to
us
right?
B
I've
been
talking
about
reusing
c
code,
but
what
does
it
have
to
do
with
with
with
pini
and
and
the
answer
is
a
lot
of
the
kernel
data
structures
on
the
on
the
c
side
are
self-referential,
right
and
and
the
the
the
problem
with
being
self-referential,
and
by
self-referential
I
mean
that
there
are
fields
in
it
that
point
to
itself
right.
It
can
be
directly
direct
direct
points
are
filled
to
another
field
or
to
the
top
of
the
struct,
or
it
can
be
indirect
right,
like
a
field
point
somewhere
else
that
points
somewhere
else.
B
That
eventually
comes
back
to
this
to
this
object,
so
we
can
have
this
self
references
can
be
direct
or
indirect,
but
we
have
lots
of
those
we
have
them
all
over
the
place
in
the
column.
In
some
cases
we
actually
need
them
to.
We
need
these.
These
objects
to
be
pinned.
Oh
actually,
so,
what's
the
relevance
of
being
self-referential
to
to
pinning
and
and
the
relevance
is
if
there
is
there
are
these
self-references?
B
We
wanted
to
have
this
pins
so
that
they
cannot
be
moved
and
because,
when
they
are
moved,
then
this
pointers
don't
get
updated
and
I'll
show
you
in
more
details
in
a
second
how
this
happens
so
in
in
in
on
the
seaside.
We
actually
have
some
cases
when
we
need
to
to
pin
the
the
these
objects
from
the
beginning.
So,
right
after
we
allocate
the
object,
we
need
to
to
pin
it
before
we
can
use
it.
B
B
There
are
some
fields
here,
some
fields
here
and
then
this
is
the
wait
list.
There
are
two
fields
within
this
wait
list
next
and
previous
right
when
we
initialize
them
next
points
to
to
to
the
to
wait
list
and
previous
also
points
to
to
to
the
waitlist.
So
this
is
this
is
the
the
part
that
I
say
it's
circular,
right
and
and
and
in
here
we
have
the
self-references
that
I
was
talking
about
and
this
in
this
case
it's
actually
a
direct
one.
B
We
have
the
object
pointing
to
to
itself
okay,
so
this
is
on
the
seaside
on
the
on
the
rust
side.
So
this
is
this
is
our
abstraction
and
and
if
you
look
at
it,
it
basically
boils
down
to
a
mutex
and
the
object
that
we
are
protecting
and
and
the
the
the
implication
of
having
this
this
new
types
here
is
that
we
have
the
same
sort
of
thing
happening
on
the
rust
side
as
well,
of
course,
because
it's
just
wrapping
this
the
seaside,
but
we
have
our
mutex
instance.
B
Here
we
have
some
fields
here
which
are
coming
from
mutex.
We
have
some
other
fields
here
also
coming
from
mutex,
but
we
also
have
our
data
down
here,
but
the
idea
is
that,
next,
if,
if
in
our
new,
for
example,
we
initialize-
we
call
that
mutex
in
it.
What
we'd
see
is
that
we
have
this
next
pointing
to
to
to
the
list
head
and
the
same
thing
for
previous,
because
we
would
also
point
there
and,
as
I
said
before,
there's
an
issue
with
that,
and
I'm
going
to
show
you
this.
B
This
diagram
is
this
is
the
one
that
brings
this
this
home
right.
So
this
is
how
things
are
initialized.
This
is
how
things
are
done
normally
in
in
rust.
There's
not
nothing
unusual.
Here,
okay,
we
have
some
struct
that
has
some
in
the
field
that
is
a
mutant
x
right
and
this
ref
is,
is
our
implementation
of
arc,
so
we're
trying
to
create
a
ref
counted
instance
of
my
struct
that
has
a
mutex
in
it
right.
B
So,
if
we,
if
we
look
at
how
this
would
be
would
run,
would
would
be
executed
at
the
runtime.
This
is
what
what
we
get
right.
There
is
a
a
a
call
to
to
mutex
due
we
initialize
our
pointers.
If
you,
if
we
call
mutex
in
it,
then-
and
this
is
allocated
on
the
stack
okay
and
then
what
happens
is
revenue
is
called
with
with
this
mutex
initialized
on
the
stack
and
in
fact
there
are,
there
are
two
stack
instances
here
that
can
be
optimized
out.
B
So,
given
that
this
optimization
exists,
I
consider
that
there's
just
one
for
our
argument
here.
So
so
we
are
in
this
state,
okay
and
then
we
call
revenue.
Rev2
actually
allocates
some
memory
on
the
heap
right,
that
is,
that
is
ref
counted
and
eventually
we'll
we'll
have.
We
have
something
like
this.
We
have
mutex
and
we
have
the
ref
count
up
here,
but
this.
B
Right
and
what
it
does,
is
it
moves
this
argument
here
into
this
new
heap
allocation,
so
this
object
that
we
had
initialized
here
with
those
pointers
pointing
to
itself
are
just
going
to
be
copied
bit
by
bit
to
the
to
the
heap
right,
and
so
the
situation
we
end
up
with.
Is
this
one-
and
this
is
the
the
this
our
source
of
of
problems
right?
B
It's
because
now
our
heap
allocated
and
ref
counted
thing
that
has
a
mutax
in
it
now
has
pointers
to
the
stack
right
and
so
not
only
to
the
stack
to
an
object
that
existed
in
the
stack
and
it's
going
to
be
automatically
popped
from
the
stack.
So
it's
pointing
to
to
remember
it's
a
dangling
pointer,
basically
and
whenever
we
try
to
actually
access
this
we'll
mutate
this
this.
This
stack
region-
and
this
is
really
bad.
That's
that's
the
the
the
source
of
lots
of
vulnerabilities.
B
It's
these
sorts
of
things
that
c
allows
you
to
do
and
you're
trying
to
prevent
that
from
from
happening
on
the
rust
side.
So
what
what
did
we
do
to
to
to
address
this
problem
right?
So
we
we
defined
this.
This
new
constructor
and
we
had
to
make
it
make
it
unsafe
right.
So
the
idea
here
is
that
the
mutex
initialization
doesn't
happen
in
our
new.
Our
new
just
uses
some
uninit
version
of
of
that
mutex
and
the
safety
requirement
which,
which
we
annotate
here.
B
So
this
is
actually
a
convention
that
we
use
miguel
talked
about
having
improved
conventions,
a
lot
of
improved
like
well
new
conventions
that
we
can
enforce
from
the
get
go,
because
this
is
a
new
project.
So
we
actually
have
this
convention
where
we
say,
if
you
define
a
unsafe
function,
you
must
have
a
documentation
section
and
that
must
have
a
safety
section
in
it,
and
you
must
specify
what
it
is
that
you
need
the
caller
to
to
do
in
order
to
use
your
your
unsafe
function,
safety
right.
B
So
what
we
do
is
we
say
we
we
say
we
we
say
well,
after
initialization,
you
can
move
it,
you
can
do
whatever
you
want,
but
before
you
actually
use
the
mutex,
you
have
to
call
init
lock,
okay,
and
this
is
the
source
of
of
unsafety
for
us-
and
this
is
the
result
of
of
of
our
implementation.
The
poor
ergonomics
right,
we
have
initialization,
has
to
be
done
in
two
steps.
B
First
step
allocates
the
object
on
the
stack
and
at
the
moment
we
use
this
unique
graph
is
to
is
to
be
able
to
initialize
objects,
and
we
guarantee
there's
only
one
pointer
to
it.
This
is
a
result
of
us
not
having
the
get
mute
anymore.
So
once
the
object
is
is
is
shared.
It
cannot
be
muted,
mutated
anymore
because
it
has
been
pinned
right.
B
To
do
that
so
this
is
this
is
the
the
the
the
problem
with
the
ergonomics
that
we
have
today.
First,
we
introduced
the
the
unsafety
and
and
and
now
we're
forcing
people
to
to
to
to
have
to
call
these
mutex
units.
Now
we've
looked
into
trying
to
avoid
that,
for
example,
options
are
doing
things
like
when
you
call
mutex
in
it.
Instead
of
returning
a
mutex,
we
return
some
some
other
type
right
that
cannot
be
used
as
a
mutex.
B
Only
after
you,
you
initialize
it,
and
then
you
have
a
mutex
type.
We
could
do
something
like
that,
but
it
wouldn't
work
here,
because
we
actually
need
a
mutex
type
to
initialize
in
the
in
this
case,
because
it
is
a
mutants
to
to
to
this
inner
type.
So
this
is
this.
Is
the
the
the
the
state
we're
in
now
with
the
with
the
core
ergonomics?
What
one
possible
solution
for
for
this
is
to
is
to
change
instead
of
actually
before
I
talk
about
this
this.
B
B
The
compiler,
of
course,
checks
that
you've
specified
all
the
fields,
and
if
there
are
no
some
fields
missing
here
then
then
the
compiler
fails
the
compilation
we
want
something
similar
to
that,
but
instead
of
having
the
curly
braces
and
and
the
types
colon
and
some
function,
we
actually
want
to
have
pointers
to
these
things
and
to
be
able
to
initialize
them
in
place.
So
this
is
what
ideally
we'd
like
to
see.
B
Is
it
uses
this
field
here
to
add
this
misc
device
to
a
doubly
linked,
intrusive
and
circular
linked
list?
The
same
type
of
list
that
we
talked
about?
One
thing
that
I
should
I
should
say
here,
there's
actually
a
talk
from
or
q
a
with
linus
torvalds,
where
he
talks
about
taste
in
programming,
and
this
is
actually
the
example
that
that
he
uses,
because
one
possible
solution
for
us
would
be
to
to
say.
B
Oh,
let's
not
use
lists
of
this
type
in
the
kernel
right,
so
let's
use
something
else,
but
perhaps
in
the
future.
We
may
try
to
do
this,
but
this
is
not
something
realistic
now.
Another
thing
that
I
should
say
is
I've
worked
on
other
kernels.
So,
for
example,
I
worked
on
the
on
the
nt
kernel,
which
has
huge
code
base.
I've
seen
some
bsd
kernel
code
too,
and
all
three
of
these
one
data
structure
that
they
have
in
common
is
this
sort
of
of
of
of
lists.
B
B
B
B
It's
not
unsafe,
so
it's
okay
to
allocate
this
because
we
don't
have
the
self
reference
yet.
But
then,
when
you
call
register,
you
are
required
to
pass
a
pinned
version
of
the
thing
so
between
new
and
registered,
you
have
to
pin
your
your
object
before
you
can
you
can
you
can
call
register
and
and
and
and
between?
These
two
is
where
the
our
unsafe
requirement
is
in
most
cases
and
we'll
talk
about
it
in
the
next
slide.
B
But
before
I
I
go
there,
I'd
like
to
point
out
that
we
actually
have
this
helper
function
here.
That's
called
new
pins
that
will
merge
these
two
things
and
there's
no
unsafety
involved
here
right.
So
what
it
does
is
it
allocates
a
memory
pins
it
and
then
calls
calls
register
and
here's
the
type
it's
a
pin
box
right.
It's
just
not
it's
not
just
pin
it's
a
pin
box.
The
problem
with
this
is,
is
that
well
it's
not
a
problem.
B
B
You
actually
need
to
to
to
pin
your
your
object
right.
So
the
idea
is,
if
you
have
a
struct
and
in
this
struct
you
have
multiple
objects
that
need
to
be
pinned.
Okay,
for
example,
you
have
a
mutex
inside
the
thing
you
have
a
misc
registration.
Maybe
you
have
a
net
field
registration.
They
all
need
to
be
pinned
right,
so
you
actually
have
the
option
to
do
the
dynamic
allocation,
but
but
then
what's
happening
is
you
have
a
field?
B
They
do
care
about
the
layout
and
how
to
optimize
the
cache
lines
such
that
fields
that
are
used
together
are
closed
and
are
close
together
and
share
a
cache
line.
So
this
is
the
situation
we
have
now
to
to
to.
Actually,
if
we
have
the,
in
this
case,
we
have
the
outer
object.
P
is
pinned
the
object
itself
is
pinned
right,
but
the
fields
of
this
object
are
not
necessarily
pinned
and
to
claim
that
they
are
pinned.
B
For
for
this
sort
of
thing
right
so,
for
example,
in
in
in
annotations
right,
so
when
you,
when
you
declare
your
my
struct
right,
you
could
perhaps
add
some
annotations
where
you
say
misc.
If
my
strut
is
is
paint
then
then
misc
is
painted
too
right
and
it
would.
It
would
prevent
us
from
doing
all
the
bad
things
that
that
one
can
do
by
doing
the
structural
pinning
in
projections
right,
but
also
allow
us
to
to
do
something
like
this.