►
From YouTube: OpenZFS Developer Summit Part 1
Description
http://www.beginningwithi.com/2013/11/18/openzfs-developer-summit/
Matt Ahrens introduces and leads discussion; Platform Panel: illumos (Chris Siden), FreeBSD, Linux (Brian Behlendorf), and OSX (Jurgen); Platform-independent code repository (Matt Ahrens)
A
A
All
right
so
do
other
other
priorities
that
people
think
are
kind
of
missing.
From
this
I
know
several
people
have
expressed
interest
in
kind
of,
like
I
asked
adam,
to
give
a
talk
on
his
experience
with
like
doing
his
performance
evaluation.
So
this
is
kind
of
like
a
more
less
interactive
talk,
but
I
think
it's
very
interesting
for
developers
as
opposed
to
you
know,
end
users
may
not
have
the
skills
to
do
some
of
the
in-depth
analysis
that
you
know
that
we
want
this
room
to
have.
A
C
B
A
E
E
F
A
A
So
maybe
we
can
do
a
show
of
hands.
We
need
to
start
with
this
page.
So
john
kennedy
wrote
the
zfs
test
suite
and
ported
it
to
the
new
framework
that
he
wrote
test
runner,
which
is
now
in
inno,
lumos,
right,
right,
cool.
So
are
people
interested
in
talking
about
not
just
that
test
suite
but
kind
of
testing
on
zfs
in
general
like
what
we
need
to.
A
Several
people
were
interested
in
talking
about
the
interactions
with
the
vm
subsystem,
in
particular
on
linux,
in
mac
os
people.
Let's
total
people
interested
all
right
is
kirill.
Here
there
you
go
scalability
issues
like
using
zfs
on
really
large
memory
large
number
of
disks.
It
can
only
scale
up
to
128,
gigs
yeah.
That's
what
I
heard
on
the
mailing
list.
A
Multi-Tenant
zfs
using
zip
all
right,
so
I'm
trying
to
sort
these
based
on
number
of
hands.
So
if
I
make
this
over
here,
just
let
me
know
maybe
like
a
lightning
talks.
You
know
five
ten
minutes
on
what
do
we
have
lunch?
That's
a
good
idea!
Maybe
lunch
just
before
just
after
something
like
that
right,
cool.
H
A
Okay,
cool
and
I'll
kind
of
draw
the
dividing
line
like
maybe
these
I
think
these
top
ones.
I
saw
lots
and
lots
of
hands,
and
then
these
these
bottom
through
a
few
left,
stands
all
right.
Open,
gfs
code
repository
cool
performance
on
fragmented
pools,
george
has
done
a
bunch
of
work
in
this
area,
so
I
know,
there's
been
a
bunch
of
interest
on
both
the
linux
and
the
previous
g
fronts,
on
creating
a
fma
work
alike
for
handling
like
spares
and
stuff.
Like
that.
I
think
this
is.
A
This
would
be
mainly
like
a
discussion
session
more
than
like.
I
don't
know
that
anybody
has
a
pair
of
talk
on
this,
but
is
there
interesting
fma?
It
stands
for
fault
management
architecture,
it's
part
of
lumos,
but
it
handles
like
detecting
when
a
device
or
a
controller
has
died
and
then
like
taking
appropriate
actions
like
bringing
in
a
spare.
So
my
new
saying
is
that
on
these
other
platforms,
there's
no
kind
of
automatic
hot
spare
activation,
so
I
think
that's
kind
of
the
most
visible.
J
A
A
L
A
bunch
of
time,
with
one
customer
in
particular,
gathered
a
bunch
of
data
that
led
into
some
of
the
work
that
matt
and
george
and
I
have
done
in
the
last
year,
or
so
in
terms
of
performance
commitments
and
some
of
the
work
that
george
still
has
ongoing.
So
that
would
be
presenting
a
bunch
of
the
either
the
raw
data
or
some
of
the
investigations.
We
went
through
with
some
examples
about
how
we
collected
this.
C
A
A
So
there's
eleven
that
I
saw
at
least
half
the
people
raised
their
hands
and
then
three
more
so
we
have
about
six
hours
of
presentations.
So
if
we
stick
to
a
half
hour
per
presentation,
we
can
talk
about
all
the
things
that
at
least
half
the
people
raise
their
hands
for
so
I
would
suggest
that
we
kind
of
that.
We
just
do
that.
Does
anybody
want
to
make
an
argument
that
they?
A
Brian
they're,
I
don't
know
how
much
broader
buy-in
for
some
of
that
stuff
is
needed
right.
So
I'm
not
sure
like,
like
the
vm
porn
that
should
be
talked
about,
because
I
think
we
might
be
doing
stuff.
That's
gonna
at
least
impact
the
code
on
linux
and
we'd
like
that
to
go
upstream,
so
we
wanna
do
it
in
a
way,
that's
acceptable
to
everybody.
But
I
don't
know
that
that
involves
everybody
necessarily
it
might
be
a
little
too
nitty-gritty.
A
D
A
I
A
I
A
All
right
cool,
so
I
guess
maybe
what
are
they
be?
Quite?
What
are
the
big
questions
that
we
want
these
guys
to
answer?
I
think
one
is
like
what
is
the
state
of
zfs
on
your
platform
like?
Is
there
a
bunch
of
stuff
that
I
guess,
first
of
all,
how
does
how
does
it
work
like?
Is
it
in
the
main
code
base?
I
think
most
of
us
kind
of
know
these
general
answers,
but
just
let's
start
with
that
quickly
like?
Is
it
like
production
quality?
Are
there
people
using
it?
A
Which
is
a
government
research
agency,
he
actually
ported
zfs
to
linux
and
they're,
using
zfs
on
linux
at
some
of
the
world's
biggest
super
computers
jurgen
london
is
working
on
the
zfs
on
mac
os
port.
When
did
you
start
on
it
february?
I
think?
Okay,
so
just
in
less
than
a
year
gone
from
nothing
to
cfs.
A
Yes,
sorry
illuminous
advocate,
so
he
gives
a
lot
of
the
illuminous
process,
which
is
all
the
changes
that
I
make
and
shin
works
on
dfs
on
freebsd,
for
ag
systems
and
is,
I
think,
currently
the
most
active
kind
of
person
in
pulling
changes
from
lumos
into
freebsd.
Yes,
so
first,
what
do
I
ask
each
of
you
to
kind
of
tell
like
what?
How
is
the
fs
on
your
platform
in
just
like
a
couple?
A
Okay
sentences
for
the
linux
exists
in
adult
repository
in
github.
At
the
moment,
if
building
has
a
lot
of
different
kernels
in
linux,
it's
a
kind
of
a
diverse
environment.
Stability
is
good.
People
use
it
in
production.
We
use
it
in
production.
We
depend
on
the
production.
I
know
a
lot
of
other
people
have
picked
it
up
too.
A
The
first
question
people
ask
there
is
some
debate
about
whether
it's
okay
or
not,
I
think
the
there
is
no
debate
from
pretty
much
anybody
about
building
it
from
source.
So
if
you
take
the
two
independently
and
build
them
both
from
source,
I
think
that's
fine.
I
think
there
are
differing
opinions
about
whether
you
can
put
the
two
together
as
a
binary
and
ship
it
as
a
product.
We
believe
that's
fine,
other
people
believe
different.
A
So
I
think
you
know
the
concern
about
the
license.
Discussing
licensing
issues
here
is
that
it's
very
easy
to
rattle
on
something
that
none
of
us
can't
really
do
anything
about.
That's
all
like
I
think
it's
totally
it's
a
legitimate
question.
It's
just
something
that
has,
I
think
you
dealt
with.
You
know
this
way
more
than
you
have
ever
wanted
to
yeah.
The
good
news
is
that
questions
are.
J
D
C
K
K
My
most
common
question
is
probably
why,
in
the
linux
version,
as
opposed
to
all
the
other
versions,
but
the
zfs
code
itself
is
kind
of
platform
independent,
whereas
they
had
a
very
nice
separation
between
the
solaris
layer,
the
fdl
layer
and
the
defense
code
itself
and
whatever
kernel
you're
running
and
that's
what
I
wanted
and
the
watercolor
setup
so,
whereas
previously
and
lumos
are
very
integrated
building.
Because
that's
why
I've
started.
B
And
like
how
did
zfs
get
there
right?
So
lumos
is
the
like
open
source
fork
of
open
solaris
that
was
created
when
oracle
closed.
The
solaris
development
stops
developing
solaris
in
the
open
and
then
there's
a
bunch
of
like
niccenta
and
delfix,
and
some
other
giant
some
other
companies
that
base
products
off
of
it,
and
so
a
lot
of
those
companies
do
zfs
development
and
it
goes
back
into
the
illumos
core
and
I
think,
that's
very
similar
to
like
the
freebsd
model
of
how
things
work
basically
and.
I
A
Cool
so
next
question,
I
think
maybe
you
can
tell
us
like
what
is
the
development
model
like
on
your
platform,
so
how
do
changes?
How
do
changes
happen
like
I
have?
Let's
say
I
have
some
great
idea.
I
make
some
changes.
I
want
to
get
it
into
zfs
on
your
platform.
How
does
that
happen
and
then
kind
of
what
platforms.
B
A
Yes,
and
then
also
like
you
know,
where
do
the
changes
come
from
on
your
platform
like
like?
Are
you
pulling
changes
from
some
other
platform?
Primarily,
are
you
talking?
You
know,
how
do
you
interact
with
other
people?
Other
communities
is
that.
Does
that
question
sort
of
make
sense
yeah,
I
think
so?
Okay,
so
at
least
I'll
try
and
explain
what
happens
on
linux
today.
So
we
do
all
of
our
work
out
in
the
open
on
github,
where
we
happen
to
host
all
of
our
stuff.
A
A
We'll
cherry
pick
the
commit
from
alumnus
review,
it
make
sure
it
looks
same
for
linux,
who's,
doing
that
who's,
doing
that,
like
cherry
picking
and
then
who's
doing
the
reviewing
in
that,
the
good
news
is
that
I
would
say
the
community
on
the
left
side
has
stepped
up
a
lot.
Occasionally,
we'll
get
lots
of
people
just
random
people
who
see
this
feature
go
into
illumos
and
say
I
want
that.
A
That's
cool
all
right,
so
the
commit's
there
right
so
they'll
go
get
it
for
the
most
they'll:
rework
it
for
linux,
they'll
test
and
open
a
pull
request
on
github.
It's
at
that
point
that
I
pretty
much
review
everything
that
goes
in,
but
I
really
want
to
get
more
reviewers
so
often
I'll
tap
other
people
to
look
at
a
change
and
make
sure
it
looks
sane
or
tested
more
broadly
and
then
assuming
everything
looks
good.
A
We
run
it
through
our
automated
regression
testing
and
whatnot
I'll
get
immersion
to
our
tree,
but
basically
we
don't
take
things
in
big
chunks
from
a
lumos
without
reverb,
without
reviewing
and
testing
and
merging
everything
real
carefully,
because
there
are
some
platform,
specific
differences,
and
we
don't
want
to
get
bit
by
that.
So
we
lag
and
we
don't
just
bring
things
in
blind.
But
the
good
news
is
a
lot
of
reporting
listeners
done
by
other
people
in
the
community
who
just
want
stuff,
occasionally
I'll
see
people
pop
up
from
other
platforms.
A
Like
the
freebsd
side,
we'll
say
we
made
this
cool
feature
on
freebsd
I'd
like
to
see
the
linux
too.
Here
it
is,
and
I've
reworked
it
for
the
linux
side,
so
it
just
goes
through
the
normal
review
and
process.
What
I'd
love
to
see
from
opencfs
is
a
more
formalized
review,
process
and
more
eyes
on
the
code
as
things
go
in,
it
feels
like
every
every
platform
kind
of
does
their
own
thing
right
right
now,
okay,
so
on
on
linux.
Right
now,
are
you
pretty
much
the
sole
code
reviewer?
A
I
am.
I
certainly
review
everything,
but
I'm
not
the
sole
reviewer.
Okay
right,
so
I
my
eyes
are
on
it
before
it
goes
in
the
tree,
but
I
try
to
find
other
people
who
know
about
the
subsystem
if
I
can
to
look
at
it
before
it
goes
in
and
often
one
of
the
nice
things
about
the
linux
community
is
it's
pretty
because
the
trees
on
github
and
it's
all
built,
it's
really
easy
to
build
against
whatever
lens
distribution
you're
using.
So
it's
really
easy
to
tap
people
in
the
community.
I
ask
this
a
lot.
A
Here's
a
patch,
it's
safe,
go
test.
It
right,
come
back.
Tell
me
better
or
worse.
I
mean
how
did
it
help
your
workloads
that
kind
of
stuff,
so
we
gotta
try
to
get
a
lot
of
feedback
from
the
community
before
something
goes
in
and
then
who
is
there
a
process
around
like
that
final
commit?
Is
that
just
like
you
know
you
are
the
one
person
who
signs
off
on
it
or
is
it
like
a
group
of
people
who
can
connect
to
the
actual
source
space?
A
So
right
now
it's
just
me,
but
I'd
like
to
expand
it
so
I'll
sign
off
on
it,
and
then
I've
got
a
automated
automated
build
infrastructure
at
livermore,
where
I
run
it
through
a
suite
of
automated
tests
on,
like
I
don't
know,
20
different
linux
distributions
and
somebody
get
builds
clean,
they're
all
they'll
pass
and
they
all
run
the
regression
tests
and
nothing
fails.
We'll
merge
it
in
so
I'd
love
to
see
more
of
that
kind
of
automated
testing.
More
broadly
done
with
the
test
infrastructure
that
you
guys
are
working
on
at
delfix.
A
K
Yeah,
it's
a
lot
simpler
than
awesome,
so
well,
we're
based
on
github
as
well
created
a
project,
and
I
think
maybe
two
or
three
committers
at
the
moment.
So
it's
very
empty
and
it's
mostly
me
every
now
and
then
we
basically
do
a
giant
merge
with
upstream
linux
and
then
spend
a
couple
of
days
just
making
sure
it
actually
runs.
E
K
C
K
K
A
K
There's
there
was
apple
with
original
apple,
which
then
became
mac,
cfs,
okay,
which
is
pool
version,
eight
okay,
and
then
there
is
zero
by
don
brady,
but
that
is
close
source
in
it.
They
haven't
released
a
new
version
for
quite
a
while
and
they've
gone
through
a
cfo
change
cto,
so
we
don't
really
expect
them
to
be
continuing
their
product,
at
least
that's
what
it
looks
like,
whereas
the
port
that
I
started.
K
H
K
I
touched
that
a
little
bit
in
the
beginning,
but
no
that's
fine,
and
basically
I
wanted
the
separation
that
linux
have
between
the
kernel,
the
solar
sporting
layer
and
then
the
zfs
and
they've
got
a
really
beautiful,
drawn
lines
where
between
the
projects.
Whereas,
if
you
look
at
freebsd
or
lumos,
it's
a
bit
more
ingrained
you're,
not
really
too
sure
which
header
is
the
kernel
header
or
which
is
the
solar,
header
or
cfs
and
so
on.
And
I
want
to
autocomp
as
well,
which
I
didn't
want
to.
C
A
Previous
d
porting
previously
also
has
a
supporting
layer
that
they
probably
think
is
pretty
good.
So
I
think
it
would
be
really
interesting
to
try
and
find
like
what
are
what
are
the
things
that
people
think
are
good
about
those
different
brain
layers
and
figure
out.
How
do
we
create,
like
the
super
set
of
all
the
good
parts
of
that
when
we
create
an
actual
independent
code,
repo.
K
C
A
B
Model
yeah
so
lumos,
who
kind
of
hinted
at
it
earlier,
has
advocates
who
are
people
with
permit
access
or
push
access
to
our
github
repo
and
the
model
is
basically
you
get
reviews
on.
We
have
a
zfs
mailing
list
zfs.org,
I
think,
and
you
get
reviews
there
and
then
you
send
it
to
a
list
of
advocates
that
say:
here's
who
reviewed
it
and
assuming
that
you
got
it
reviewed
by
people
who
so
for
zfs
changes.
B
B
It
gets
pushed
into
lumos
and
we've
had
a
couple.
I
think
some
freebsd
changes
came
back.
We
don't
there's
no
one
really
actively
pulling
things
from
other
distros
or
the
other
os's.
So
but
sometimes
we
got
some
free
freebsd
changes
because
forget
who,
but
someone
from
frequency
actually
got
the
most
turkey
yeah.
B
And
I
mean
we
have
in
general
for
zfs
commits
we
have
rules
about
kind
of
unspoken
rules,
but
you
have
to
run
all
of
our
test
suites.
So
sometimes
when
someone
who
does
who's
not
familiar
with
dfs
development
but
just
reports,
a
change
from
another
system,
I've
generally
been
willing
to
use,
like
dell
fixes
systems
to
run
the
test
suites
for
those
people,
so
very
excited.
B
Port
or
is
it
just
constantly
moving
the
core
almost
doesn't
have
any
versions
or
releases
it's
up
to
different.
If
you
you
fork
it,
and
then
you
have
your
releases
of
your,
so
joint
has
releases
and
delphics
has
released,
but
the
core
lumos
is
just
a
just
a
trunk
that
changes
whenever
you
just
branch.
Whenever
you
want.
D
C
I
A
So
in
3bsd,
just
how
can
you
kind
of
who
is
involved
in
doing
the
reporting
process
and
reviewing
process,
like,
I
guess,
like
brian,
was
saying
that
they
really
review
like
every
change
from
illumos
like
really
really
carefully
and
then
like?
Go
through
this
whole
testing
process?
And
it's
like
what
one
you
know.
Maybe
somebody
from
the
community
does
the
actual
report
and
then
brian
reviews
and
commits
it
and
tests
it.
So
how
does
that?
A
A
I
B
C
L
I
A
A
Originally,
we
don't
run
the
vfs
test,
suite,
which
I
really
would
like
to
run
because
that's
kind
of
the
big
hole
in
our
test
coverage
at
the
moment,
because
it
tests
more
like
the
zfs
octal
interfaces
for
like
send
receive
that
kind
of
stuff.
So
I
wish
we
had
more
coverage
there,
but
we
do
run
all
that
stuff
in
every
commit.
So.
A
I
don't
know
so:
we've
run
certainly
coverity
and
claim,
I
think,
are
to
pretty
much
a
long
set
of
code
analyzers
on
the
linux
board
and
they
found
a
lot
of
stuff.
But
it's
a
lot
of
false
positive,
usually-
and
we
just
haven't-
had
the
manpower
to
run
down
all
the
false
positives
and
get
it
reporting
the
code
clean
I'd
like
to
get
to
the
point
where
it
does
do
that,
and
then
we
keep
that
you
know
at
zero.
Basically,
it
seems
like
the
most
effective
way
to
run
those
tools.
A
Right
is
they're
useful
once
you
eliminate
all
the
defects
and
then
you
kill
anything
as
soon
as
it
pops
up
yeah,
but
we
haven't
had
the
manpower
to
get
to
that
point.
I
think
it'd
be
great
if
we
could
maybe
pursue
that
through
open
cfs,
I
mean
clang
is
an
open
source.
Analyzer
I'd
be
happy
running
that,
but
it
has
already
had.
A
Than
I
mean,
I
think
lynch
is
in
some
ways
more
useful
than
those
tools
because,
like
the
vfs
code
is
actually
linked
clean,
like
you
know,
it
has
to
be
clean
to
integrate
it.
So
it's
obviously
less
checks
that
are
done
by
these
more
sophisticated
tools,
but
you
know
they're,
actually
all
checked
they're
they're.
All
all
those
rules
are
good
too
any
other
tools
that
people
I
know
I
know
like,
for
example,
on
freebsd
there's
the
lock
order,
the
witness
stuff.
A
H
A
K
J
J
Is
a
preprocessor
that,
depending
on
whether
you're
doing
stuff
for
like
faa,
certification
or
so
multi-decision
coverage
or
single
decision
coverage,
whatever?
Basically,
it
injects
instrumentation
points
and
then
catches
those
as
you
go
through
different
decision
points,
and
so
it
can
tell
you.
Basically,
if
you
run
a
test
suite
against
the
program,
how
this
stuff,
no
bullseye's,
not
bulldog's,
not
hugely
expensive,
though
okay.
A
A
With
other
parts
of
the
community
or
what
is
it,
and
in
particular,
with
an
eye
towards
what
how
we
as
a
community,
can
help,
I
would
say,
there's
a
couple
issues
on
the
linux
side.
Linux
suffers
from
a
few
problems
that
previously
moves
don't
or
a
few
more
restrictions.
I
guess
not
problems.
Necessarily
things
like
stack
size
are
much
more
of
a
concern
on
linux.
A
I
don't
know
how
memory
management
is
done.
This
is
totally
different
than
the
other
platforms,
so
people
will
make
changes
upstream
and
illuminos
that
are
perfectly
reasonable
on
freebsd
or
alumnus,
but
they're
just
non-starters.
On
linux
we
don't
control
the
entire
environment,
so
we
have
to
live
within
the
kernel
and
the
restrictions
the
kernel
imposes.
We
have
to
follow
so
that
code
will
change
in
linux.
It
would
be
nice
to
maybe
socialize
some
more
of
those
relatively
minor
restrictions
upstream,
so
we
don't
have
quite
as
much
term
in
our
code,
jurgen
biggest
pain,.
K
C
K
K
K
I
C
K
B
I
G
C
F
C
F
A
A
So,
first
of
all
like
what?
What
is
the
point
of
what
are
the
goals?
So
all
that's
the
stuff
that
people
just
mentioned
getting
simplify
getting
the
changes
into
every
platform,
simplifying
the
slurry
supporting
layers
that
exist
on
different
platforms.
I
don't
know
about
I've
looked
at
the
linux
one,
but
I
know
that
the
freebsd
guys
have
complained
about
like
how
ugly
the
solaris
boarding
layer
on
their
platform
needs
to
be
in
order
to
take
in
zfs
changes
from
lumos
without
modification
it.
A
You
know,
there's
crazy
things
where
it's
like.
Oh
there's,
a
function
called
like
you
know,
cv
broadcast
and
it
broadcasts
the
condition
variable,
but
it
does
it
a
little
bit
differently
than
the
way
that
the
loom
of
someone
expects
it
to
so.
You
have
to
like
do
lots
of
nasty
hacks
with,
like
include
with
header,
with
the
c3
processor,
to
say
like
first,
you
include
the
zfs,
the
zfs
header
file,
which
you
know
undefines.
A
A
A
So
the
idea
would
be
to
basically
have
like
a
live
sequel,
expand
the
libs
equal
so
that
we
can
test
more
and
more
of
the
code
in
userland
and
create
yeah
so
basically
and
create
a
like,
not
solaris,
but
open
zfs
porting
layer
which,
on
each
platform,
would
would
implement
their
own,
including
illumos,
and
then
including
the
use
the
posix
userland
version
of
this.
That
would
be
part
of
the
code
repository
so
yeah
today.
A
So
you
know,
I
think
the
the
kind
of
first
bar
would
be
to
get
everything
all
the
code,
except
for
like
the
zpl,
the
z-ball
and
like
vw
disc,
because
those
are
really
not
platform
independent
today
or
at
least
not
entirely
platform
independent.
You
know
the
z,
the
zpl
is
very
different
on
you
know
linux
versus
freebies.
Do
you
say
so?
A
You
know
we
could
just
like
the
easiest
thing
would
be
just
say,
like
oh
take
everything,
that's
an
illumos
and
like
plug
it
into
another
code
repository
but
like
the
make
files
on
the
most
are
very
heavyweight.
Obviously,
because,
like
they
can
compile
like
everything,
a
million
different
ways,
you
know,
use
the
land,
kernel,
etc,
etc,
so
figuring
out
like
what
to
do
there.
A
K
A
We
just
like
use
whatever
illuminates
interfaces
we
want.
Whatever
interfaces
exist
in
the
kernel
we
use
them,
and
then
you
know
if
that
code
compiles
into
this
equal.
Also,
then
we'll
add
like
a
stub
in
in
the
libsy
pool.
You
know
kernel.h
or
whatever,
so
the
idea
would
be
to
say
no,
you
can't
do
that.
You
can
only
use
interfaces
that
are
defined
in
this.
You
know
one
header
file,
that's
like
zfs,
you
know
zfs
kernel
interfaces
zk
whatever,
so
you
know
we
would
create
our
own.
A
Like
you
know,
mutex
enter,
you
know
case
stat
interfaces
km,
allocation
interfaces,
everything
and
then
these
would
all
be
like
macros
or
you
know,
little
small
little
functions
that
wrap
the
interfaces
on
each
platform,
so
the
tricky
thing
is
figuring
out
like
which
of
these
interfaces
should
be
included,
and
then
what
are
the
semantics
of
these
interfaces
because
you've
heard
from
google
that,
like
you
know,
conditional
variables,
exist
on
every
platform,
but
they
work
a
little
bit
different
on
every
platform.
Right,
so
I
mean
for
condition
variables.
A
A
So
this
is
kind
of
a
very
easy
thing
that
we
could
just
say:
okay,
all
the
code
in
the
repository
you
know
you
want
to
declare
a
tunable.
You
use,
you
know
a
macro,
that's
like
zk
for
zfs
kernel
interfaces,
cisco
whatever
and
then
on
freebsd.
That's
just
like
a
pass
through
to
you
know,
cisco
upon
and
then
on
other
platforms.
You
know
if
they
don't
have
that
infrastructure,
then
it
just
declares
the
global
variable.
A
Another
example
is,
like
you
know,
on
a
lumos.
We
use
this
cv
time
date
high
res
with
this
special
condition.
Variable
and
like
this
doesn't
exist
on
any
other
platform,
so
you
know
creating
like
a
something
that
logically
wraps
this,
like
you
know
sleep
until
this
time
and
then
you
know
on
lumos.
Maybe
we
do
this
on
some
other
platforms.
You
know,
maybe
they
have
like
nano
sleep
or
something
like
that.
A
Does
this
kind
of
make
sense,
at
least
when
I'm
proposing
all
right
so
there's
a
ton
of
open
questions
here
which
I'd
like
to
get
you
guys
to
put
on,
one
of
which
is
like
what
libraries
should
be
included.
So
you
know
when
we
compile
in
new
zealand
today,
like
libsy
pool
you
know,
it
depends
on
like
live
envy
pair
live
yell,
the
view
live.
All
these
are
interfaces
that
also
exist
in
you,
know
the
solaris
kernel
and
then
in
like
the
boarding
layers.
A
So
when
we
create,
if
we
create
this
independent
code
repository,
should
the
code
of
these
libraries
also
be
in
the
code,
the
open
zfs
repository
versus?
Should
these
just
be
dependencies
that
you
know
that's
up
to
each
platform
to
make
sure
that
they
have
it?
You
know.
So
you
know.
There's
the
code
in
the
repository
just
has
a
make
file.
A
So
I,
like
I
mean
that's,
that's
cool,
I
think
one,
the
the
flip
side,
the
flip
side
to
that
is
that
it
makes
it
harder
to
change
those
interfaces
right
so
like,
for
example,
I
added
a
bunch
of
stuff
to
the
bend
repair.
That's
used
in
zfs
like
the
fnv
list
stuff
that
wouldn't
be
like.
That
would
be
much
more
difficult
if
those
were
in
separate
code
repositories
right.
So
it.
I
A
F
A
Yeah,
I
don't
think
so.
I
mean
I
totally
agree
that
I
don't
know
most
like.
We
already
have
these
things,
so
it's
fine.
I
mean
other
platforms
like
what.
How
do
you
implement
these
or
like?
Where
do
you
get
the
code
for
these
libraries
today?
So
on
linux,
things
are
a
little
more
complicated
because
every
distribution
does
their
own
thing.
So
we
have
no
control
over
what
versions
of
these
libraries
get
installed
about
them,
so
we've
actually
kept
them
intrigued.
A
So
we
have
a
version
of
like
live
environment
that
we
build
in
the
kernel
and
then
we
build
it
in
user
space
as
well,
and
that's
the
only
same
thing
I
think
to
do
on
linux,
just
because
we
don't
have
control
over
that
we
could
ship
our
own
versions.
I
suppose,
but
you
want
to
override
the
one
the
distribution
provides.
No,
probably
not
so
you.
A
We
certainly
need
to
keep
a
copy
of
some
of
these
for
the
kernel
right,
so
the
kernel
side
of
this,
where
they
use,
we
don't
have
adl
trees
or
any
of
that
so
they're,
not
things
that
exist
in
a
links
kernel
so
either
way
we're
keeping
a
version
of
them.
So
it's
kind
of
weird
to
keep
two
copies
right,
so
we
just
built
that
on
both
sides.
A
It's
I
mean
my
only
concern,
so
my
only
concern
with
keeping
with
not
keeping
in
the
tree
is
that
then,
like
linux,
you
know
you
guys
have
to
have
your
copy
of
all
of
the
lib
envy
pair
the
libyan
code
and
then
freebsd
like.
If
they
are
doing
the
same
thing,
then
they
also
have
to
have
their
own
copy
of
that,
and
then
lumos
has
its
own
copy
of
that.
J
Yeah,
I
mean
yeah
one
other
thing
about
some
of
these
additional
libraries
is
that,
for
instance,
previously
has
talked
about
having
an
nd
pair
library,
with
a
pse
license
to
use
elsewhere
in
kernel.
What
we
really
need
is
just
the
expectations
of
how
that
library
is
going
to
be
used.
So
if
the
interface
is
well
defined,
then
we
can
make
our
md
pair
implementation
have
all
the
features
necessary
to
support
whatever
comes
from
opencfs.
A
A
D
A
Cool
all
right,
so
then,
there's
also
a
bunch
of
questions
about
like
what
are
you
know?
If
we
create
this
independent
code
repository,
then
you
know
we
need
to
figure
out
like
what
are
the
rules
around
like
how
we
how
we
make
changes
to
that
code
repository.
So
you
know
what
testing
are
we
going
to
require?
What
code
are
we
going
to
require?
A
A
And
you
know
kind
of
what's
the
the
process
like
what?
What
tools
are
we
going
to
use?
Who
do
you
talk
to,
and
I
think
probably
one
of
the
things
that
we
could
easily
rather
on?
Is
you
know
how?
How
do
we
document
the
changes?
So
you
know,
for
example,
like
do
we
document
with
like
with
the
bug
report
as
we
do
on
illumos
today,
or
do
we
document
it
with
like
commit
comments?
As
you
know,
I
know
like
on
linux:
that's
really
heavily
used.
A
A
I
would
propose
that
we
kind
of
stick
with
the
illuminous
model
of
code,
reviewing
meaning
that
everything
must
be
code
reviewed
by
somebody
who
is
not
the
person
who
committed
it
may
the
changes
have
the
changes
should
be
tested
in
new
zealand
and
in
at
least
one
kernel.
There
should
probably
be
relatively
few
committers.
A
D
A
Opengfs
development
experience
would
be
like,
let's
say
I'm
on
linux.
That's
why
I'm
using
my
desktop.
I
care
about
my
changes
getting
into
linux.
What
I,
what
I
do
is,
I
you
know,
create
my
diffs
against
linux
and
if
they're
only
touching
you
know
this
the
files
that
are
part
of
opencfs,
then
those
files
are
identical
on
on
in
the
linux
codebase
as
in
opengfs.
So
I
create
my
changes.
A
I
test
them
on
linux,
then
I
I
guess
maybe
maybe
what
we
would
need
is
some
way
for
you
to
actually
check
out
the
opengfs
code
repository,
make
your
changes
there
and
then
like
apply.
Those
changes
like
automatically
to
the
like.
Basically
cherry
pick
them
over
to
the
zfs
on
linux
code
repository,
so
you
can
compile
both
the
the
zfsl
mix,
one
for
the
kernel
and
then
the
open
zfs
one
for
userland
test
it
in
userland.
A
Somebody
would
review
that
and
then
integrate
it
into
the
code.
Opengfs
and
then
zfs
on
linux
would
pull
that
change
into
the
zfs
linux
code
repository
so
that
that
kind
of
perspective,
that
kind
of
procedure
is
very
similar
to
what
somebody
developing
like
if
you're
developing
on
freebsd
today-
and
you
want
to
get
your
change
onto
every
platform,
you
kind
of
have
to
do
all
those
same
things
except
that
you're
dealing
with
illumos
rather
than
open,
zfs.
Okay,.
D
D
L
A
Think
that
those
changes
would
be
rare,
I
mean
given
the
scope
of
like
you
know.
We
aren't,
including
this
like
it's
pretty.
I
think
it's
relatively
rare
that
you're
gonna
see
changes
that
are
actually
not.
They
might
only
be
useful
in
one
particular
use
case,
which
is
more
common
on
a
given
platform.
Like
you
know,
maybe
it's
really
useful
for
the
desktop
stuff,
and
you
know
linux
is
really
heavily
used
on
the
desktop
and
other
platforms,
not
so
much.
A
A
Yeah,
so
I
think
like
in
in
reality
like
each
repo,
is
going
to
be
lagging
a
little
bit
behind
the
the
common
repo
just
as
they
like
behind
the
lumos
today,
but
hopefully
that
daddy
would
be
that
they
would
lag
less
so
behind
it,
because
they
would
have
been
involved
in
the
code
review
process
from
day.
One
they
would
be
able
to.
You
know
know
that
it's
only
using
supported
interfaces,
so
it
isn't
going
to
break
when
you
pull
it
into
each
platform.
A
J
A
Definitely
a
legit
concern,
so
my
the
thing
that
I
don't
like
about
the
documenting
stuff
in
the
comments
is
that
they
can't
be
changed
afterwards
so
like
if
somebody
said,
if
all
the
documentation
lives
there
in
the
comments-
and
it
says
oh
I'm-
making
this
change,
I
did
this
diagnosis.
I
figured
out
that
this
is
the
problem
you
know
and
you've
written
like.
You
know
the
whole
book
on
this
and
then
later
on,
you
discover,
oh,
that
analysis
is
totally
wrong.
That
guy
did
not
understand
what
he
was
doing
at
all.
A
A
In
the
in
the
future,
right
I'm
going
to
propose
that
we
use
github,
git
and
github
and
so
another
like
something
that
I
think
theoretically
would
address.
All
these
concerns
is
get
notes,
but
I
don't
know
because
I've
never
used
them
and
I
don't
know
like
how
they
get
transmitted,
and
you
know
it's
more
of
a
big
unknown,
because
I
don't
think
that
any
of
us
is
using
them
very
flexible
right
now.
H
A
A
A
A
If
people
lie
that
this
is
possible,
I
think
I
should
be
very
skeptical
about
it.
Actually
I
mean
I'd
like
to
get
there,
but
I
think
maybe
the
scope
of
the
changes
between
the
platforms
is
underestimated.
Yeah
yeah,
I
mean
they're
fairly
expensive
on
links
and
they
go
deeper
than
people
would
like
to
admit.
I
mean
the
core.
Is
the
same.
I
don't
know
the
other.
A
I
C
A
Might
be
actually
another
area
that
I
that
we
need
to
elaborate
on
is
like
we
probably
should
separate
out
live
gfs
into
like
the
live
gfs.
That's
dealing
with
like
pretty
mount
points
and
device
files
and
like
all
that,
crap
put
that
in
its
own
file,
make
that
part
of
the
zk
interface
and
say
each
each
platform
implements
that
independently.
A
A
A
Repository
to
like
add
this
k
layer
and
like
tease
things
apart
or
we
could
you
know
we
could
just
create
a
new
repo
with
the
files
identical
to
what's
in
illumos
today
and
then
you
know
work
on
refactoring
in
there,
the
idea
being
that,
like
today,
all
the
other
platforms
are
pulling
from
lumos.
So
if
we
just
take
the
code,
that's
in
the
most
put
into
another
repo
like
then
ever
it's
the
same
for
everybody
else.
A
It's
only
more
work
for
lumos,
you
know
initially
and
then,
until
we
can
kind
of
get
to
this,
nirvana
of
everything
is
better
for
everyone,
but
it
sounds
like
you're,
I'm
kind
of
hearing
two
things
one
is
we
have
a
lot
of
look
like.
We
have
a
lot
of
local
changes
in
in
linux.
That
will
make
this
really
really
hard,
but.
A
L
J
D
I
guess
the
one
thing
for
us
that
join
is
that
very
often
all
of
our
changes
to
zfs
interact
with
some
other
subset
other
subsystems
in
the
kernel.
So
a
lot
of
our
work
goes
with
into
containers
or
zones
so,
but
for
us,
it's
just
kind
of
a
question:
how
do
we,
actually
you
know
we're
going
to
be
creating
new
zk
layers
or,
like
are
all
the
interaction
with
containers?
D
Actually,
you
know
to
illumina
specific
since
yeah,
I
know,
there's
lxc,
which
is
maybe
mainline
or
jails,
have
their
own
stuff,
but
I
have
no
notion
of
what
those
apis
are
is
for
us.
That's
kind
of
one
of
the
big
questions
is:
how
do
we
for
us
a
lot
of
our
innovation
work?
Is
it's
when
we
straddle
multiple
components
of
the
system,
as
opposed
to
kind
of
keeping
it.
A
H
D
It
which
is
we're
slowly
working
on
pushing
up
quickly
of
the
I
o
throttling
the
the
limit
stuff
will
integrate
also
with
zones.
We
do
a
lot
of
kind
of
I
o
kind
of
collection,
like
case
stat,
work
which
is
based
on
per
container,
basically,
because
you
can
also
have
an
arbitrary
collection
of
cfs
volumes.
D
Potentially
yeah,
I
mean
right,
I
guess
for
us
that
we
for
at
least
us-
I
don't
know
about
other
folks
that
there's
always
that
kind
of
different
integration
with
other
aspects.
So
for
us,
it's
not
always
as
clean
as
just
saying
we
as
we
don't
work
on
core
zfs
as
much
as
we
work
on
integrating
zfs
with
other
aspects
of
the
system.
So
for
us
it's
more
of
a
question.
I
A
And,
like
obviously,
the
first
step
like
we
need
to
go
enumerate,
what
all
these
interfaces
are
and
be
like.
Oh
you
know
they're
this
on
this
platform
this
this
on
this
other
platform
and
then,
like
you,
know,
merge
all
those
lists
of
requirements
together
on
linux.
Does
it
it
does
the
zone
stuff
hookup
with
linux
containers,
not
at
the
moment
we
haven't
even
explored
doing
that,
but
I
think
even
just
that
fact
that's
used
on
two
platforms.
Like
means
they
should
probably
be
part
of
the
common
repo
sure,
yeah.
D
I
guess
I'm
just
saying
kind
of:
in
general,
we
have
this
kind
of
this
interaction
yeah,
I
think
through
how
we
actually,
I
guess,
for
us
one
of
the
questions
of
60.
How
do
we
add
to
the
zk
lighter
like
realistically
for
us
would
be
like
we'll
add
it
in
archery
yeah,
we'll,
probably
push
that
to
a
lumos
and
then
maybe
that'll
eventually
make
its
way
up
to
the
general
stuff,
because
if
you're
adding
new
interfaces,
then
someone's
have
to
go
right
for
linux
and
freebsd.
A
I
think
you
guys
provide
that
version
exactly
I
think
you
have.
The
thing
is
like:
if
you're
adding
to
the
zk
layer,
you
have
to
provide
the
implementation
for
username,
which,
in
in
a
lot
of
cases,
is
going
to
be
the
no-op
implementation
sure.
So
hopefully
it's
easy
for
other
platforms
to
pull
that
no
op
implementation
from
the
userland
into
the
kernel
and
like
it's
not
a
big
deal,
so
I
mean
I
think
that
the
idea
should
be
that
it
should
be
relatively
lightweight
to
change
the
zk
interfaces.
A
F
A
Use
yeah,
so
let
me
get
to
another:
let's
go
through
this
slide
and
then
get
to
a
slide
that
talks
a
little
bit
about
what
you
just
mentioned.
So
you
will
also
need
to
decide
what
what
kind
of
non
interface
level
but
like
constraints,
need
to
apply
to
the
code.
So,
for
example,
you
know
linux
has
these
smaller
stack
sizes?
A
Should
we
just
say
like
in
opengfs,
you
have
to
assume
that
the
stack
is
small
and,
like
maybe
you
know,
when
we
do
when
we
run
in
userland,
we
explicitly
create
small
stacks,
so
that's
actually
tested.
You
know
kind
of
going
to
the
lowest
common
denominator
that
you
know
creating
the
requirements
so
that
it'll
actually
work
everywhere
and
you
don't
unexpectedly
break
linux.
Obviously
you
know
maybe
we're
leaving
some
formats
on
the
table
on
other
platforms,
but
probably
not
that
big
of
a
video
right
like
allocating
memory
is
pretty
pretty
cheap.
A
You
know
what
language
should
we
use
c99,
except
for
on
linux
is
a
c
c
like
30
years
ago.
You
know
what
compiler
should
it
be
compiled
with.
I
think
like
we're
going
to
have
to
support
multiple
compilers,
but
you
know
what
kind
of
make
what
what
make
files
do.
We
provide
to
compile
all
this
stuff
in
new
zealand.
A
What
kind
of
stack
analysis
tools
do
we
use
so
like
lint
or
you
know,
adding
in
other
of
these
cool
psych
analysis,
stuff,
other
kind
of
like
requirements
like
you
know,
we
talked
about
freebsd's,
witness,
lock
ordering
stuff.
It
would
be
really
cool
if
we
could
actually
make
it
witness
clean.
You
know
and
exclusively
document
what
things
don't
work
and
actually
have
that
be
checkable
on
any
platform,
with
like
a
username
implementation
of
that
yeah.
H
So
sorry,
the
stack
thing
is
it
possible
under
linux
to
mark
some
threads
with
a
larger
stack.
The
reason
why
I
asked
is
because
in
previously
we
had
a
small
stack
forever
and
one's
becoming
one
of
those
things
where
you
start
thinking
about
the
environment,
and
I
I
know
you're
supposed
to
think
of
the
environment
in
which
you're
programming,
but
it
becomes
listening
because
it's
a
constant,
like
you
know
how
exactly
they
have
to
know
how
much
that
we
have,
and
it's
can.
C
A
A
So
those
you
know,
I
had
definitely
had
the
idea
here
of
like
creating
bigger
stacks
for
threads,
that
are
that
are
owned
by
zfs.
Like
the
you
know,
sync
threads
and
zio
threads
like
maybe
we
could
do
that
on
linux,
but
we
probably
can't
go
change
like
the
size
of
every
thread
in
the
entire
system.
So
so
the
deal
on
linux
is
no.
You
can't
the
current
provides
a
million
things
or
larger
than
8k
stacks
platforms.
Well,.
A
H
C
A
One
community,
like
one
community,
has
a
constraint
and
like
they
can't
change
it
and
we
kind
of
have
to
decide
like
as
the
larger
zfs
community
like.
Are
we
going
to
like
take
that
burden
on
collectively
or
are
we
just
going
to
say
like
no
like
screw
you
like
stock
sizes
are,
are
you
know
one
mag,
and
if
that
doesn't
work.
A
Yeah
for
you,
you
get
you
get
something
on
the
stack
and
for
you,
you
get
to
became
a
malika,
and
usually
I
can
do
both
or
either
yeah.
So
maybe
we
haven't
seen
like
any
real
performance
concerns
from
us
moving
stuff
from
the
stacked
and
heap
which
we've
done
a
lot
of
in
the
existing
company.
I
would
say
that
was
maybe
the
majority
of
our
changes
before
the
fs
code.
A
That
much
it's
just
a
different
way
of
coping
right
yeah.
I
mean
that
that's
kind
of
my
experience
as
well
with
like
doing
some
of
these
changes.
Is
that,
like
the
slab,
allocator
is
really
fast.
So
it's
not
that
big
of
a
deal,
I
would
say
the
more
insidious
problems
we've
had
with
stack
and
zfs.
Are
there
a
couple
places
where
it's
recursive
that
kills
us
when
you
go
through
like
a
traverse,
dp
vfs
person.
A
You
know
what
we
had
to
do,
otherwise
it
doesn't
work.
Well,
I
mean
it's
less
dirty
than
like
making
it
non-recursive,
which
is
good.
You
know
yeah,
like
I,
don't
think
it's
that
dirty
to
say
like
oh,
you
know,
like
you
you're
putting
a
block
pointer
on
the
stack.
That's
too
much,
so
you
can't
involve
it.
It's
not
the
end
of
the
world.
A
So
it's
what
we
did,
but
I'm
good
to
hear.
Other
people
have
similar
issues
with
that,
all
right
so
getting
to
some
of
the
issues
of
github.
So
our
proposal
was
basically
to
use
github
for
storing
the
code,
but
not
necessarily
use
all
of
github's
aspects.
So
you
know
there's
a
lot
of
different
things
that
github
can
do
like.
You
know,
code
review
and
bug
tracking,
but
we
don't
necessarily
have
to
use
their
version
of
it.
A
F
So
go
back
to
my
previous
question,
so
I
wanted
to
just
ask
a
question
about
the
previous
slot.
So
all
those
items
that
you
had
so
you
can
catch
some
of
these
in
the
review
process.
But
often
it's
the
dirty.
Does
it
build?
Because
what
do
you
have
a
slide?
Where
you
know
do
you
have
an
idea
that
there
will
be
like
a
build
farm
of
all
the
platforms
that
no
anyone
pushes
a
change?
We
don't.
A
A
I
mean
that
would
be
great
to
have,
but
my
like,
my
idea
is
that
we
make
it
so
that
when
you
build
it
in
you
like
you
build
it
in
user
land,
you
test
it
in
user
land
and
we
constrain
the
userland
environment
sufficiently
that
we
know
that
it'll
work.
We
know
we
have
high
confidence
that
it
will
work
on
other
platforms.
So
you
know,
for
example,
we
restrict
the
stock
size
and
use
the
land.
We
compile
it
with
the
right
flags
and
use
land
that
are
the
superset
of
everybody
else's
flags.
A
A
G
I
think
it's
fine
for
not
getting
started,
it'd,
be
really
nice
to
have
to
be
able
to
take
a
dip
and
just
push
it
to
the
cloud
and
say
build
this
and
test
this
for
me.
So
I
don't
have
to
set
up
everything
like
we've
set
some
stuff
up
locally
for
that,
but
it'd
be
nice
to
have
some
official
website.
I
can
point
to
you
and
say:
hey
I
tested
this.
Look
at
the
the
pastor
failed
instead
of
me
just
saying.
D
You
can't
yeah,
we
have
some
folks
that
joined
who've
done
that
with
node.js,
but
it's
also
pretty
junky
like
you
will
drop,
they'll
drop
messages,
and
things
like
that.
So
another
thing
to
kind
of
just
think
about
is
that
if
we
wanted
any
kind
of
poll
or
post
receive
hooks,
we'll
need
to
have
a,
we
could
still
use
github,
that's
kind
of
the
as
the
main
thing,
but
you
might
want
to
consider
having
to.
A
L
A
So
you
know
how
do
we
get
there
from
here
like
this?
Is
a
lot
of
stuff
to
do?
We
can't
do
it
all
at
once,
so
I
think
the
idea
would
be
to
start
with
I'd
like
to
propose
that
we
start
with
just
like
creating
an
independent
code
repository
putting
this
putting
the
code
from
lumos
into
there,
and
then
you
work
on
reducing
the
diffs
and
creating
the
zk
wrappers.
So
you
know,
for
example
like
I
I
guess
this
is
actually
a
kind
of
a
question
like.
A
Should
we
work
on
reducing
the
diffs
in
both
directions,
like
should
we
say,
start
convert
like
converting
the
linux
stuff
to
use
c99
in
these
files,
so
that
then
the
diffs
are
smaller.
When
you
do
like
a
switch
over
or
should
we
just
say
like
that's
fine,
and
you
know
linux,
will
you
know
linux
can
pull
from
this
repo
and
you
know
kind
of
work
on
reducing
their
dips
on.
You
know
on
your
own
schedule,.
A
A
And
all
that
just
the
process
to
associate
with
it
and
then
maybe
finding
it
sounds
like
we're
kind
of
tacitly
volunteering
a
lumos.
What
we
need
is
like
two
distributions
to
get
married
in
this
repository.
Yes
right
and
like
we
have
a
willing
bride
in
olympus
and
we're
looking
for
a
suitor
in
mac,
os
freebsd
or
linux.
L
D
H
I
B
B
B
Place
to
start
because
then
you
can,
you
can
get
to
the
end.
You
can
get
to
a
point
where
you're
like
here
are
the
20
files
that
go
into
the
common
repo
and
they're.
Already
the
same,
so
we
can
immediately
start
pulling
because
otherwise
you're
in
a
weird
situation,
where
some
people
are
pushing
these
zk
wrappers
to
this
central
repo,
while
we're
still
pushing.
I.
B
The
other
distros
are
like
freebsd
is
still
pulling,
but
linux
is
trying
to
use
both
our
like.
It
seems
like
you
have
a
really.
We
should
have
one
upstream
that,
like
stays
the
same
for
a
while
until
we're
close,
I
think
there's
a
safe
point
to
switch.
Otherwise,
I
feel
like
there's
going
to
be
moving
the
changes
around.
You
can
get
much
harder
if
we
have
kind
of
we're
pretending.
D
This
is
an
upstream,
but
it's
not
really
upstream
yeah.
I
also
think
it
seems
like
given
that
we're
not
certain
of
what's
going
to
be
in
the
ck
wrappers
it'll,
be
a
lot
easier
for
us
to
actually
go
figure
that
out
actually
get
that
working
on
the
different
platforms
and
get
that
in
all
the
trees
before
we
then
try
and
separate
out
into
something
else
right.
C
B
C
A
B
A
A
G
C
J
The
the
rules
for
interacting
with
this
particular
repository
are
these
rules,
which
are
slightly
different
than
what
they
are
for.
Alumos
and
yeah.
We've
done
the
separation,
here's
the
flag
day.
That
invites
because
it's
probably
not
gonna,
be
just
an
individual
like
in
the
freebsd
community
that
gets
to
has
the
time
to
go
through
and
work
on,
the
ck
porting
layer
and
all
that
stuff.
It's
gonna
be
a
whole
bunch
of
us,
but.
L
J
L
I
B
J
You
know
it
moving
to
github
and
having
these
new
rules
for
how
you
interact
with
this
repository
and
all
that
kind
of
stuff,
as
laying
the
groundwork
for
how
the
freebsd
community
can
interact
better
with
that
repository
and
actually
make
these
things
happen.
So
that's,
I
think,
the
reason
why
I
find
it
compelling
that
there
be
a
split,
even
if
it's
just
a
lumos,
that's
pulling
from
it
to
begin
with,
because
I
think
that
very
quickly
that
that
situation
would
change
just
because
you
you
have
documented
hey.
This
is
open.
B
Do
you
find
that
completely
argument
that
makes
sense?
It
seems
like
what
we
need
to
do
then
is
separate
from
other
just
some
from
other
operations
operating
systems
figure
out
a
way
to
have
something
to
break
out
something
that
ignoring
you,
don't
even
need
the
ck
layer
at
all
just
break
out
something
that's
independently,
testable
and
start
making
the
process
go
through
there.
I.
B
A
To
your
point
like
that,
it
doesn't
need
to
be
completely
independently,
testable
from
day
one,
because
the
idea
would
be
like
you
just
take.
You
know,
see
those
changes.
These
dfs
files
live
in
the
open,
zfs
repo.
We
pull
them
into
a
lumos,
we
test
them
on
lumos.
We
do
everything
on
lumos
and
then
you
know
that's
great
right.
A
D
F
D
We
have
to
do
the
coordinate
effect,
not
just
to
open
zfs.
We
have
to
make
sure
that
what
we
put
into
aluminum
is
matches
the
changes
in
the
rest
of
the
system,
so
you
have
to
figure
out.
How
am
I
going
to
actually
so,
for
example,
for
us
we're
just
going
to
push
through
a
limitless
drawing
same
way,
people
are
going
to
push
their
products
repository
at
first
and
that's
generally
the
folks
as
well.
Everyone
doesn't
want
us
to
just
put
untested
changes,
but
everybody
at
the
same
time.
D
H
D
Git
sub
module,
strictly
speaking
in
illumos
at
some
version,
or
does
it
because
is
its
own
copy
of
it,
the
code?
Because
then,
if
it's
its
own
copy
of
the
code,
we
have
to
deal
with
basically
pushing
two
different
changes
which
are
actually
physically
different
like
for
us
to
test
these
things.
We,
like
the
user
line.
D
Stuff
is
kind
of
okay,
but
like
we
have
to
basically
for
us
most
of
the
testing
is
basically
we
have
a
huge
multi-tenant
system
like,
and
you
basically
need
to
have
these
coordinated
changes
with
the
rest
of
the
rest
of
the
kernel.
It's
not
an
independent
change
to
just
cfs,
especially
you
have
these
codependent
changes
between
the
kernel
and
zfs,
and
how
do
we
make
sure
that
when
we
had
the
separate
repository
for
us
at
least
like
how
do
we
coordinate
those
changes?.
H
I
mean
we,
we
do
things
like
this,
not
but
sort
of
across
different
facilities
between
us.
So
I
mean
I
mean
we
look.
What
sorry,
for
example,
for
our,
for
instance,
our
our
build
and
everything
like
that,
so
our
gui
will
use
certain
features
of
the
kernel
and
we
just
can't
have
it
out
of
out
of
sync.
So
we
manage
the
changes
to
actually
both
systems.
If
we
were
to
keep
them
all
together,
we
wouldn't
be
able
to
maintain
the
separation
that
allows
us
to
track
freebsd,
better
interaction.
A
A
J
D
H
A
That,
like
what
everybody
has
today
is
like,
could
this
a
could?
Basically
could
they
see
all
the
code
is
different
in
all
this
like
one
is,
for
you
know
the
kernel
one
is
for
user
land,
one
is
for
the
gui
and
there
isn't
any
code.
That's
like
this,
the
same
copy
of
the
code
in
all
these
things,
but
now
we're
saying
that
we're
going
to
create
like
open,
cfs
and
then
lumos
has
a
copy
of
the
open.
A
D
B
This
zfs
repo,
the
goal,
isn't
that
you
check
out
both
repos
and
you
need
both
repos
to
build
right.
It's
that
you
take
what's
in
the
zfs
repo
and
put
it
into
the
right,
so
you
would
turn
this
into.
It
would
still
be
two
pushes,
but
one
push
would
have
everything
and
the
other
pusher
drive
only
the
zfs
changes.
I
J
D
A
C
J
L
J
J
J
D
H
We
have
a
lot
of
people
who
really
want
to
contribute
to
it,
but
it's
there's
a
lot
of
confusion
so
about
how
those
changes
are
going
to
go
in
and
and
what
the
process
is.
So
I
I
think,
there's
going
to
be
something
around
this
really
like
opens
up
a
process
for
many
communities
contributing
towards
it.
I
think
we'll
see
a
lot
more
changes
that
are
very.
A
I
Illumis
manages
that
upstream
is
up
to
a
loophole,
so,
for
example,
if
if
they
want
to
say
you
know
we're
just
we're
just
going
to
pull
we're,
not
accepting
kind
of
you
know
integrations
into
these
files,
then
that's
one
way
of
managing.
That's
what
we've
talked
about
it.
If
they
would
say
look
a
loomis
is
just
going
to
manage
a
bunch
of
you
know,
deltas
from
the
parents,
then
that's
another
way
of
dealing
with
it
and
it's
going
to
be
a
different
kind
of
pain.
I
A
All
right,
I
think
it's
about
time
for
a
break.
I
think
you
know,
maybe
the
one
thing
that
we
should
take
away
from
this
is
like
what
what
can
you
do
like?
How
is
this
going
to
help
you,
and
what
can
you
do
to
help
make
this
happen?
You
know
because
I
think,
as
you've
seen
like
this
does
not
do
much
to
help
the
luminous
right.