►
From YouTube: CDS Infernalis (Day 1) -- Ceph Plugins
Description
Videos from Ceph Developer Summit: Infernalis (Day 1)
03 March 2015
https://wiki.ceph.com/Planning/CDS/Infernalis_(Mar_2015)
A
Alright,
we're
on
to
the
next
one
here.
I
know
that
Louie
kandurata
are
both
here
with
us
to
talk
about
the
duo
of
adding
a
proprietary
key
value
store
to
SEF
as
a
pluggable
module,
as
well
as
general
support
for
plug-in
installation
upgrade
Loic
I
think
you
had
a
plan
here.
Did
you
want
to
go
ahead
and
just
break
this
one
down
for
us
sure.
B
Can
you
hire
me
yep,
so
we
currently
have
to
plug
in
systems
within
stuff.
It
does
not
show
because
SEF
is
actually
shipped
as
a
whole,
but
within
it
there
are
CLS
plugins
classes,
no
wrote
a
nice
blog
post
on
how
to
use
that
to
implement
whatever
workload
you
want
to
run
on
a
given
OSD.
So
it's
a
generate
plugging
system
that
allows
you
to
run
a
binary
on
an
OSD
next
to
the
object
that
the
OSD
contains.
B
There
is
another
plug-in
system
which
is
the
errors
of
code
plug-in
system.
The
infrastructure
is
pretty
much
the
same.
That
is,
we
assume
that
there
is
a
dot
s
0
somewhere,
that
can
be
dl
opened
and
we
try
to
load
it
whenever
the
monitor
starts
or
USD
starts,
but
we
do
not
handle
that
as
a
separate
entity.
That
is
whenever
you
want
to
add
a
new
area
code
plugin.
You
actually
have
to
add
a
new
feature
on
the
OSD
to
say.
B
Okay,
now
I
have
a
new
OSD
plugin,
so
that
works
to
the
extent
that
in
firefly
and
the
error,
local
plugins
were
first
introduced,
as
well
as
the
area
code
out
feature.
So
all
that
was
a
new
feature,
but
then
in
giant
we
added
two
extra
plugins
or
RC
and
aiza,
and
we
had
to
add
a
new
feature
where
what
we
really
wanted
was
the
ability
to
just
add
a
new
plugin
independently
of
the
release
of
the
wedgie
or
the
monitor.
B
Wants
to
create
a
new
abstraction
for
the
object
store,
the
key
value
store
that
would
be
able
to
below
the
plugin
that
implements
this
abstraction,
but
not
necessarily
shipped
within
our
self.
So
that
would
be
a
third
kind
of
plug-in,
so
it
seemed
appropriate
now
our
to
try
to
make
an
effort
to
generalize
or
to
find
a
way
to
factorize
all
the
methods
to
implement
these
plugins.
B
Virada
will
be
talking
about
in
a
few
minutes.
Is
a
new
abstraction,
so
I'm
going
not
to
talk
about
this
new
abstraction
that
will
hopefully
I'll
fit
in
the
general
plug-in
system.
But
rather
I
will
try
to
explain
how
I
see
how
a
generic
plugin
would
benefit
the
original
code
plug-in
system,
because
I
know
it
best,
and
there
are
two
things
that
three
things
actually
that
I
would
like
to
discuss.
B
First,
it's
the
fact
that
when
you
have
a,
we
have
a
monolithic
up
OSD,
which
makes
it
easy
for
integration
tests
to
validate
that
it's
okay
to
go
for
the
next
20
and
we
go
to
a
lot
of
tests
to
make
sure
that
actually
works
not
only
to
redeploy
USD
on
multiple
operating
systems.
But
we
also
check
that
a
mixed
cluster
are
introducing
OS
DS
from
a
previous
version,
and
the
next
version
will
actually
play
well
together,
etc.
B
When
that
happens
on
a
rolling
upgrade,
we
want
to
be
confident
that
it
will
actually
do
the
right
thing,
so
the
integration
tests
are
essential
to
the
plug-in
system.
You
cannot
think
of
a
plug-in
system
without
thinking
that
for
plugging
author,
it
is
easy
to
trigger
numerous
integration
tests
so
that
when
it's
green,
the
plugin
authors
is
confident
enough
that
his
planning
does
not
break
something
obvious
integration
tests
such
as
unit
tests
also
units
unit
test,
cannot
really
guarantee
that
it
will
never
break,
but
at
least
it
shows
that
it
does
not
breaking
an
observation.
B
So
whenever
you
ship
a
plug-in
way,
whenever
you
have
you
break
down
the
USD
from
one
monolithic
thing
into
an
oil
d
plus
a
plug-in
ecosystem,
then
you,
you
are
facing
essentially
the
same
challenges
as
any
new
linux
distribution,
where
you
have
a
sophisticated
arm
package
system
with
conventions
on
how
to
ensure
that
the
shared
library
has
the
same
ABI
than
the
previous
one.
So
you
can
upgrade
it
without
changing
anything.
B
Well,
maybe
it
has
a
different
API
and
then
it
means
that
the
major
version
number
of
the
shared
library
changed,
and
then
we
have
to
also
change
the
binaries
that
depend
on
it
because
we
have
to
adapt
to
this
new
API.
So
all
that
our
culture
of
managing
evolving
packages
which
have
different
life
cycles
and
make
them
manageable
in
the
context
of
stable
ways.
That
would
be,
for
instance,
the
surgeries,
and
this
is
something
that
we
do
not
have
to
invent
and
that
we
we
shouldn't
invent
instead.
B
B
Then
it
would
be
shipped
as
an
RPM
for
RL
or
sent
OS
or
as
a
dub
dead
for
a
debian
or
ubuntu,
and
whenever
you
want
to
install
it
instead
of
pulling
a
just
a
dot
s,
oh,
you
would
actually
call
the
packaging
system
of
the
operating
system
on
which
you
reside
and
these
packaging
system
well
not
only
ensure
you
that
you
match
the
release
constraints,
but
also
will
report
errors
to
you
in
a
way
that
is
familiar
to
any
any
system
administrators.
So
that's
the
same.
C
With
the
beam
yeah,
we
sorry
if
I
can
rep
for
just
a
second.
We
punted
on
this
a
little
bit
in
the
past
by
just
saying
the
data
cells
like
we
don't
worry
about
distribution
or
anything.
The
data
says
just
have
to
be
in
the
right
directory
and
they'll
get
loaded
and
with
the
EC
plugins.
We
added
this
additional
constraint
that
the
version
string
has
to
match
exactly
so
that
we
know
that
the
the
ABI
the
interface
hasn't
drifted
and
that
the
plugin
will
actually
work.
C
So
just
so
you're
saying
that
we
essentially
sort
of
continue
doing
that,
but
we
sort
of
open
up
the
possibility
that
we
put
them
in
a
separate
package.
We're
like
the
RPM
first
check,
for
example,
would
just
have
a
requires
line
that
says
that
it
tested
be
installed
with
the
exact
same
version
of
supposed
e
that
kind
of
way
you're
getting
it.
B
Yes,
so
what
I'm
saying
is?
Essentially,
there
would
be
a
set
of
packages
that
are
extracted
from
Seth,
as
it
is
now
with
that
are
good
citizens
and
have
strong
constraints,
and
they
are
official
in
the
sense
that
okay,
we
went
through
all
the
tests
that
we
usually
go
through
and
even
to
the
extent
that
says
depends
on
these
packages.
So
we
split
these
packages.
We
have
a
few
more
packages
for
the
safe
plugins,
but
there
are
for
the
moment.
B
So
it's
not
that
many
and
whenever
Seth
installs
itself
it
also
pulls
them,
so
it
will
not
actually
disrupt
anything.
It
will
also.
It
will
feel
like
it's
monolithic
still,
but
it
will
open
the
possibility
that
we
create
new
packages
that
can
have
a
life
cycle
of
their
own
because
they
rely
on
a
mechanism
that
makes
that
possible.
We're
currently.
B
An
update
and
that's
okay,
where
I
guess
I
would
like
to
have
feedback.
So
the
real
problem
which
is
internal
to
SEF
is
how
do
we
make
sure
that
we
can
actually
use
this
bad
plug
in
our
in
a
given
context?
So
this
this
is
different
for
the
CLS
plug
in
this
is
different
for
the
Auraria
plug
in,
and
it
will
probably
be
different
for
the
objects
or
plugin
for
the
image
of
coke
plugin.
Essentially,
you
need
OSD
and
all
months
to
be
able
to
load
one
plug-in
before
you
can
start
using
it.
B
B
B
If
they
succeed,
they
will
report
back
that
their
list
of
installed
plugin
is
this,
including
the
new
plugin,
and
so
the
OSD
map
would
have
to
contain
for
each
way
the
a
list
of
plugin
that
they
currently
have
loaded
and
whenever
the
least
audio
is
this
in
the
US
do
not
have
the
required
plugin,
then
this
plug-in
would
be
added
to
the
white
list
of
plugins
that
can
be
used
to
create
a
poll,
because
there
is
no
way
for
unworthy
to
know
in
which
pool
are
it
will
participate?
So
every
always
we
have.
C
C
So
I
mean
we
had
something
almost
like
complicated
before,
but
it
was
basically
the
solving
the
distribution
problem
so
that
you
would
load
the
plugins
on
the
these.
Are
the
classes
at
the
time,
you'd
load
the
classes
on
the
monitor
and
it
would
store
them
and
then
it
would.
It
was
responsible
for
distributing
them
all
to
do
SDS,
and
it
was
just
it
was
just
complicated
right.
We
eventually
realized
that
you
know
if
this
is
what
packaging
systems
are
designed
for.
C
Let's
just
did
see
administrators
job
to
make
sure
that
the
software
is
actually
installed
in
every
node
I'm.
Not
the
cluster
is
so
to
do
that
for
you,
what
you're
proposing
is
a
little
bit
different,
because
it's
assuming
that
it's
already
installed.
It's
actually
not
know
it's
like
verifying
that
its
installed,
but
it's
not
actually
installing
it
for
you,
I
was
loadable,
but
it
in
my
mind.
It's
still
it's
still,
if
not
completely,
almost
in
the
same
category
of
a
lot
of
complexity.
B
That's
the
trouble,
ideally
that's
something
that
is
done
by
an
external
tool
and
whenever
this
external
tool
taste
to
the
cluster
okay,
you've
got
to
go
it's
installed
everywhere.
Then
we
could
blindly
tell
to
self
okay
I'll,
create
that
maybe
we
should
just
lie
on
that.
I
think.
C
C
Mean
my
say,
it
is
fragile,
but
it's
also
a
lot
of
work
to
like
sort
of
battle.
The
guard
rails
to
prevent
people
from
shooting
themselves
in
the
foot.
So
my
my
inclination
would
be
the
first
thing
to
do
is
just
make
sure
that
if
you
screw
it
up-
and
you
have
a
pool-
that's
created
with
a
plugin
that
you
don't
have
that
you
loudly
complain
about
it
by
like
logging
into
a
nice
central
place
where,
when
things
go
wrong,
the
administrator
can
sort
of
quickly
diagnosed.
The
problem
is,
and
as
long
as
we
do.
B
B
If
we
are
to
check
if
an
OSD
actually
is
able
to
load
the
plugin
as
it
claimed
then
yeah,
but
that
seems
maybe
it
will
take
a
very
long
time.
I,
don't
see
what.
C
I
mean
I
think
we
just
we
could
just
not
do
that
right,
I,
guess
that
there
goes
old
Nick
again.
We
could
just
say
that
it's
the
administrators
have
to
mix
to
ensure
that
the
salt
everywhere
and
then
you
go
and
create
the
pool
and
if
it
doesn't
work
it's
because
yet
been
screwed
up
and
there
will
be
an
error
message,
so
they
can
figure
it
out.
Do
your
shares
of.
A
C
C
B
C
That's
better
yeah
I
mean
I,
think
my
maybe
we
want
to
solve
this
problem
initially,
but
my
I
think
the
place
to
start
with
would
just
be
to
to
not
try
to
solve,
solve
this
and
just
make
it
easy
to
diagnose.
If
you,
if
you
screwed
up
so
just
make
a
lot
error
message:
I'm,
but
yeah,
so
that,
if,
if
you
know
you
create
the
pool
with
the
check
plug
in
and
it
isn't
on
some
OSD,
the
meadow
st
will
just
log
in
the
cluster
login
will
notice
right.
C
C
For
the
version
string,
I
think
my
inclination
would
be
to
continue
doing
what
we're
doing
where
it's
like
a
tightly
coupled
thing
until
we
have
a
reason
to
relax
that,
but
I'm
less
sure
about
that
I
think
if
that
that
just
causes
a
problem
for
somebody,
then
we
should
sort
of
look
at
that
and
see
that
makes
sense
to
relax.
But
the
biggest
I
think
the
biggest
thing
that
we
actually
did.
B
Well,
I
think
we
should
create
you
have
that
tightly
coupled
up,
but
making
that
using
packages
will
give
an
example,
because
the
problem
is
the
developer,
usually
is
not
a
packager,
but
in
the
case
of
the
plugin
the
package
is
actually
really
simple.
If
you
have
an
example
to
follow
so
if
we
we
do
what
we
should
currently,
but
only
we
ship
it
in
different
packages.
That's
where
my
really
easy
example
to
follow.
Yeah
yep.
C
Ok,
so
I
think
that
the
I
think
the
biggest
piece
then
I'm,
actually
the
most
interesting
part
for
me
is
there
is
really
number
one
which
is
is
how
do
we
make
a
an
infrastructure
for
loading
plugins?
That
said,
somewhat
generic
and
I
think
I'm
not
sure
if
this
really
applies
to
the
very
first
set,
a
little
more
modules
we
did
with
the
British
classes.
I
haven't
looked
at
that
in
a
long
time,
but
in
every
every
subsequent
plug-in
interface.
Since
then,
we
have
this
I
put
this
at
the
very
bottom
of
the
pan.
C
There's
this
general
pattern,
where
you
have
a
virtual,
pure
virtual
class,
that
defines
your
interface
and
with
various
methods
and
whatever
in
C++
that
are
all
pure
virtual
and
then
there
is
and
then
there's
a
factory
function
called
create
that
you
pass
the
type
and
maybe
some
other
random
stuff
and
that
actually
instantiate
some
implementation
of
that
of
that
pure
interface
and
I.
Think
that
pattern
is
actually
something
that
we
can
totally.
We
can
make
it
completely
generic
plugin
loading
frame.
Look
for
right,
like
the
most
recently
the
but
the
file
store.
C
It
follows
us
perfectly,
but
we
just
to
make
it
so
that
maybe
there's
like
a
there's,
a
stream
that
I
defies
the
interface,
the
name
of
the
interface.
So
maybe
it's
messenger
or
maybe
it's
file
store.
Oh
sorry,
object
store,
maybe
it's
a
richer
code.
You
see
whatever
and
then
there's
another
stream.
That's
that
the
name
of
the
implementation
or
the
the
type.
So
it's
a
singh
simple
file,
store
new
store,
whatever
the
actual
implementation
of
that
interfaces
and.
C
B
C
A
D
C
D
Things
you
can't
really
look
up.
Symbols
reliably,
like
doesn't,
will
abuse
like
I?
Think
it's
the
actually
C++
on
your
face
that
you're
linking
in
you
have
set
it's
like
somehow
horrible,
mangled
name.
You
can
actually
go
and
use
things
very
easily
with
like
ipod,
your
app.
You
really
have
to
have
you
Cassie
leakage,
yeah.
C
Doesn't
doesn't
that?
Doesn't
it
just
like
where
the
the
deal
open
is
only
actually
going
to
map?
Like
one
symbol,
there
were
no
symbols.
It
she's
going
to
map
the
init
function,
basically,
which
is
going
to
call
and
register
if
a
function
pointer
to
the
factory
function
and
the
factory
function
is
going
to
provide
you
with
an
instance
of
that
class,
so
I
assume
that
they,
like
the
virtual
method
table
or
whatever
for
that
class,
is
just
going
to
is
going
to
be
populated
by
the
construct
or
something
like.
D
Well,
I,
guess
you
could
let
that
pass
right
on
through
a
void
star
and
at
I.
Don't
have
everything
work
if
it's
a
custom
to
be
compiled
against
exactly
the
same
version.
Yeah.
B
Yep
that
tightens
used
it's
easier
to
to
make
a
C++
API.
That's
what
area
code
does
currently,
but
the
the
price
to
pay
is
C++
does
not
actually
hello
for
a
good
ABI,
so
it's
easier
to
make
ta
bi
instead
and
since
there
are
only
a
few
and
three
points,
it's
not
so
much
of
a
burden.
They
lose
a
plug-in
to
evolve
independently
of
the
supports
of
class
class
that
it
uses
to
implement
the
plug-in.
B
So
there
would
be
classes
to
implement
the
plugin
that
are
C++
classes
to
use
the
plugin
key
functions
that
are
C++,
but
they
are
essentially
distinct.
They
can
evolve.
They
can
have
different
life
cycles.
Currently,
the
high
Oracle
plugins
actually
compile
separately
the
C++
files
that
glow
them
to
be
implemented.
They
are
self-contained
into
1
plus
that,
but
because
the
way,
because
of
the
way
the
OSD
consumes,
the
plugin
currently
requires
that
the
c++
implementation
on
both
sides
are
exactly
the
same.
Then
there
must
be
an
exact
match
of
the
two
versions.
B
Now
there
was
a
see
ABI
between
the
two.
There
could
be
slight
variations
in
the
c++
construct
of
the
plugin,
while
still
maintaining
the
see
ABI
for
the
purpose
of
USD.
That
I
find
that
this
is
desirable
in
journal
and
that
injured
all
the
plugins
should
should
publish
a
see
ABI
instead
of
relying
on
+
+
non-id
I,
really
because
it
depends
on
the
compiler
I.
C
Mean
so
just
a
summer
is
if
we,
if
we
do
the
C++
route,
where
we
only
registered
like
the
factory
functions,
and
we
have
this
nice,
then
it
mostly
it
just
works.
The
restrictions
are
that
it
has
to
be
the
same
version
like
that.
Interface
can't
have
changed
and
it
has
to
be
the
same.
Compiler
version,
probably
yeah,.
B
C
Yeah
I
mean
it
means
that
there's
one
more
thing
for
sort
of
out
of
tree
downstream
people
to
trip
on,
but
it's
kind
of
their
problem.
I
guess
is
my
general
sentiment.
It
I
think
that
I
concerned
to
see
rat
is
that
it's
just
so
much
more
work
like
if
we
so
I
mean
the
interface
that
we
actually
want
to
do
this
with.
C
First,
probably,
is
the
object,
store
one
they're
like
50
methods,
or
something
in
that
interface
and
going
through
and
applying
the
call
points
for
like
every
single
one
of
those
calls,
and
then
the
fact
that
they're
all
buffer
lists
anyway,
which
are
else,
are
already
sort
of
implementation,
dependent
like
that
it
will
already
screw
up.
If
you
know,
different
compiler
versions
make
different
in
lighting
decisions,
maybe
probably
with
what
the
buffer
code
and
makes
me
think
that
it's
just
not
I,
don't
know
josh
does
it.
C
D
C
E
Sh,
all
right,
so
why
why
don't
you
actually
take
like
a
rapper
that
will
actually
I'm
gonna
nap
all
those
t
plus
plus
interfaces
that
we
have
about
this
floor
and
we
can.
We
can
actually
expose
that
simple
lecture
it
Kozak's
api
put
the
other
objects,
look
to
implement
that
can
be
c
or
or
anything
right.
So
we
can
expose
like
that
and
to
it.
E
So
what
I'm
saying
is
that
we
can
have
the
generic
wrapper
of
this
object,
store
that
will
actually
load
the
any
of
the
objects
toward
that
will
implement
likes
a
physics
AP
is
so
like
read,
write
and
all
those
things
that
can
actually
be
gin
like
like
see,
interface
is
right
and,
and,
and
the
rap
part
that'll
actually
will
convert
all
will
actually
implement
the
actual
objects
for
interfaces.
In
that
way.
Actually
the
rapper
will
be
loading
any
any
interface
that
will
be
actually
compliance
with
this
posix
interfaces
like
weed
right
under
churn.
C
Yeah
I
mean
you:
can
you
can
do
that?
I
think
that
the
problem
is
are
just
just
puts
you
back
into
the
other
path
where
you're
you're
having
to
go
through
the
pain
of
sort
of
defining
the
sea
calls
for
all
of
the
different
functions,
and
often
you
want
to
pass
things
around
like
buffer
lists
that
are
better.
Actually,
you
know
complicated
structures
and.
E
E
I
am
saying
that
that
the
rapper
will
take
all
this
popper
list
and
everything
that
safe
understand
and
actually
the
POSIX
interface
will
be
just
see
interface.
Will
you
send
the
Campo
enter
enter
and
the
objects
toward
that
appropriated
of
this
or
whatever
they
even
the
file
store?
And
if
it
is
XO,
can
you
can
populate
that
can
pointer
and
then
send
it
across
the
rapper
rapper
can
actually
convert
to
the
offer
list.
Yeah.
C
Yeah
you
come
in,
you
could
do
that
too.
It
just
means
that
you
have
this
extra
layer
in
between
that's
translating
data
structures,
and
it
means
that
the
I
mean
the
main
reason
why
we
we
like
using
our
Phyllis
in
generals
that
the
you
can
pass
around
the
the
reference
counting
lifecycle,
semantics
or
whatever
of
the
buffer,
so
you
could
actually
gift
ownership
of
the
buffer
to
the
backend
layer.
Even
while
you
have
current
references
whatever.
C
E
E
C
That
makes
sense
like
in
your
case,
couldn't
you
couldn't
you
do
this
and
just
be
careful
that
when
you
build
your
your
dietary
plug-in
or
whatever
that
you
just
use
the
same,
build
environment
that
that
were
you
took
or
just
ship
it
with
with
packages
that
you
built,
but
you
build
the
upstream
packages
and
then
you
also
build.
They
got
a
tree
package
in
the
exact
same
environment,
so
you
actually
control
the
built
environments.
C
It's
the
same
environment
and
then
everything
just
works
like
you
just
have
to
make
sure
the
data
so
is
built
the
same
way
that
the
the
upstream
the
sub
package
was
built
and
all
the
that
the
blinking
and
everything
just
works
perfectly
assembly
Nicias
same
compiler
version,
so
in
that
case,
then
is
is
that
is
that
too
onerous
or
restriction
like
it
saves
a
ton
of
work.
You
don't
have
to
do
any
API
translation
stuff.
You
just
have
to
make
sure
that
it's
built
the
same
like.
E
So
basically,
you
are
saying
that
a
proprietary
interfaces
right
now
are
populated.
Davis,
only
knows
about
see
top
and
probably
we're
saying
that
we
be
writing
and
c++
interface
that
understands
a
buffer
list
and
everything
and
and
actually
compile
it.
The
same
version
that
we
are
building
with
this
safe
stuff
right.
E
C
F
Sure
it's
Olivia
yeah
sure
when
you're
talking
to
put
a
generally
plugin
right.
So
do
we
really
want
to
incorporate
all
this
self
kind
of
layer
into
the
gentle
plug,
and
so
we
need
some
kind
of
an
abstraction
so
with
other
guy?
Does
it
need
to
go?
I
put
in
SF
over,
let's
start
the
buffers
or
anything
right,
so
so
that
actually
breaks
the
abstraction
just
to
achieve
some
kind
of
a
binding
towards
it
right.
F
It's
kind
of
a
table
and
15
right
now,
if
I
say
look
at
in
a
over
the
kind
of
ring
right
that
actually
beats
the
purpose
of
having
two
more
gendrich
infrastructure,
which
is
more
pluggable
into
the
surf
free
at
some
somewhere
vectors.
We
have
to
make
a
translation
from
self
buffer
list
to
a
jersey
at
face,
yeah
right
so
right.
So
that's
what
that's
where
actually
I
feel
like.
We
are
going
to
watch
right,
yeah.
C
I
think
so
I
think
so
they're
like
the
what
I'm
is
that
there
would
be
right,
there's
always
going
to
be
the
generic
plug-in
interface
on
the
step
side
and
there's
going
to
be
some
generic
storage
provider
thing
on
your
side
and
there's
always
going
to
be
a
thing.
That's
in
between
right,
and
so
the
goal
is
to
have
only
one
glue
piece
makes
our
own
either.
You
have
something:
that's
so
that
that
glue
piece
is
the
plug-in
that's
going
to
implement
the
stuff
virtual
interface.
That
can
either
be
ideal.
C
Ideally
I
guess,
for
the
simplest
thing
would
be
that
bad,
that's
just
entry
and
Seth,
and
it's
just
a
d
livin
on
the
thing
there's
sublicense
my
stuff
there.
So
we're
not
sure,
but
so
it
might
have
to
be
distributed
separately,
but
even
if
it's
distributed
separately,
that
just
means
that
we
I
need
to
dynamically
load
that
that
piece
and
I
think
we're
using
the
C++
ABI.
Can
let
you
do
that
as
long
as
that
glue
layer
is
compiled,
the
same
way
that
the
upstream
is
sort.
F
Of
heightened
alert
in
sure,
actually
the
more
selig
way
is
more
flexible
here.
The
reason
is,
you
really
do
need
to
care
about.
What
is
actually
is
a
C++
back
end,
or
is
he
back
end
right?
If
you
have
a
CA
ba,
just
need
to
say
in
it
and
internalize
the
layer
which
is
actually
extending
the
functionality
can
actually
deal
with
the
other
packet
with
it
can
be
a
C
or
C++
or
anything
maybe
in
Java.
Also,
we
don't
really
worry
about
it
right.
F
So
so
that's
where
actually
I,
like
the
lowest
point,
you
can
have
a
CA
ba,
which
is
actually
talking
to
the
C++
way
of
stuff
from
the
SEF
end
and,
and
you
can
just
go
ahead
and
then
implement
on
your
own.
What
are
the
DB
pack
and
is
right?
What
it
just
need
to
know
is
just
take
a
set
of
map
option,
maybe
amount
option
kind
of
thing
or
a
open
kind
of
options.
I
just
do
it
in
your
internal
stuff,
so
yeah
that
that
kind
of
makes
it
more
generally
Kennedy.
A
E
Think
it's
very
difficult
to
actually
I
think
I.
Don't
think
it's
possible
to
actually
get
rid
of
extra
copy
that
that
said
is
concerned
as
well.
If
we
actually
make
this
generic
I
think
that's
what
is
concern
about,
but
but
I
think
we
will
gain
this
more
generic
method
and
I.
Don't
think
that
probably
operator
Avengers,
we
will
be
actually
ready
to
make
means
comply
with
the
same
purplish
stuff
and
a
lot
of
changes
on
there
for
success.
Yeah.
C
F
C
It
just
compiled
so
if
we
can
make
if
we
can,
if
we
can
add
just
the
ability
to
dynamically
loaded,
an
implementation
of
that
and
that
thing
that
loads
of
that
can,
if
it
wants
to
it,
can
map
that,
to
a
specific
see,
ABI,
maybe
I'm.
You
know
right
my
proprietary
store
that
s
0
or
if
you
want
you,
can
make
it
map
that
to
a
generic
sea-based
ABI.
C
We
can
is
having
to
maintain
a
stable,
see
avi,
because
that
that's
a
lot
more
work,
because
we
have
done
then
we're
sort
of
on
the
hook
to
make
the
translation
between
the
c++
and
see
stuff
and
that
actually
that
work,
even
if
we
did
you'd,
still
have
to
translate
our
see
ABI
to
your
back-end
API.
But.
E
B
F
The
right
now,
the
if
I,
have
actually
look
at
the
surf
buffer
list
right.
It's
not
like
contiguous
kind
of
buffer
set.
We
have
multiple
before
section
I
represented
a
in
a
cat,
so
that
actually
the
other
back
end
should
be
able
to
understand
if
I
actually
kind
of
want
to
do
it
in
the
c++
way
to
see
and
suffer.
The
Buffalo
should
be
able
to
give
me
a
interface
where
it
s
where
my
buffer
starts-
and
this
is
my
length
of
x
buffer
right
now
to
build
that
kind
of
an
abstraction.
F
E
E
Not
only
that,
even
if
actually
we
maintain
it
say,
we
just
implement
a
plug-in
just
implement
this
shape
files
for
interfaces.
But
but
there
are
a
lot
of
lot
of
this
object
store.
We
maintain
their
own
buffers
of
right,
so
they
required
that
whenever
actually
you
said
that
you
use
that
and
you
free
that
proper
right.
So
so
in
that
case
also,
actually,
even
if
we
implement
that
we
have
to
go
through
the
same
ole
days
before
sending
it
out
to
extreme
layer.
So
you
cannot
just
use
that
there
for
all
the
way.
E
So,
for
example,
they
read
coming
read
is
actually
populating
the
buffers
from
the
proprietary
store
and,
and
they
expect
that.
Okay,
you
get
that
before
you
pop
it
and
do
a
free
call,
my
buffer
list,
so
that
actually
they
can
reuse
the
buffer.
That
would
anyway,
so
that
you're
not
into
getting
rid
of
this
extra
over
there.
C
Yeah,
although
I
mean
in
theory
you
in
theory,
you
could
so
in
practice,
usually
the
buffers
that
you
get
are
actually
contiguous.
So
it's
sort
of
you
don't
usually
copy.
But
even
if
you
wanted
to
do
like
a
zero
copy
thing
you
could
you
could
make
a
specialization,
a
child
class,
the
buffer
raw
class
inside
your
module
that
understands
your
own
internal
reference
counting
and
then
construct
a
generic
buffer.
A
C
I
mean,
maybe
maybe
your
back-end
is
is-
is
like
mapping
the
flash
memory
directly
for
the
host
memory
space,
and
you
just
want
to
let
that
go
all
the
way
up
the
stack
and
let
you
know
that
could
send
up,
though
anyway
sure
I
mean
maybe
it
makes
sense
to
follow
up.
The
discussion
on
El
Nino
is
because
I'm
not
I,
can't
talk
before
during
or
not
circles
are
okay
right.
F
C
Okay,
okay,
I
mean
just
just
get
clear:
I
don't
I'm
not
I'm
not
trying
to
like
shoot
holes.
Anybody
plans
or
anything
service
I'm,
just
hoping
that
we
can
do.
I
want
to
have
the
minimum
on
a
work
sort
of
for
both
parties
involved
and
I
and
I
drink.
There
is
actually
a
path,
that's
easier
for
everyone
very
easy
for
everyone,
as
you
should.
F
Yep,
so
I
actually
I
want
to
get
more
details
when
you
are
kind
of
Jedrek
approach,
what
you
are
suggesting
right
so
I
you
want
to
make
the
whole
key
value
store
or
the
files
for
which
is
actually
inheriting
from
the
object
store
to
be
more
generic
right.
So
right
now
we're
just
talking
about
the
key
values
for
being
a
genetic
back
end
right,
so
I.
C
Idea,
maybe
I
mean
what
I
think.
What
we're
proposing
right
here
is
just
to
make
the
existing
abstract
interfaces,
whether
they're
object,
store
or
key
value
to
be
just
basically
make
no
changes
to
the
extra
actual
interfaces
except
the
ability
to
dynamically
load
and
implementation,
and
I
think
that's
that's
easy
and
relatively
easy.
C
We
can
also
evolve
and
change
those
interfaces
and
whatever
way
improves
them
right
I
mean
there's
a
brick
as
a
Big
Branch
whip
temp,
that's
trying
to
simplify
a
bunch
of
stuff
an
object
store
to
make
it
simpler
that
the
new
source
stuff
is
all
going
to
be
based
on
I,
think,
there's
a
ton
of
stuff.
We
can
change
in
key
value
to
be
to
make
it
more
efficient
like
right
now.
Everything
that
goes
across.
C
That
interface
is
in
an
STL
structure,
which
I'm
pretty
sure
is
great,
pretty
inefficient
and
I'm
very
happy
to
see
patches
that
that's
simplify
that
or
make
any
other
or
any
other
changes
that
you
know
given
what
you
know
about
what
you're
back
in
does,
for
example,
would
make
it
more
efficient,
I'm
sure,
I'm
happy
to
hear
any
actual
proposals
to
for
that.
Yeah
yeah.