►
From YouTube: Apache TVM - µTVM Community Meeting, September 15, 2021
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
welcome
everyone
to
the
september
15th
edition
of
the
micro
tvm
community
meeting.
So
today
we've
got
a
couple
of
things
on
the
agenda
as
far
as
up
for
discussions,
so
that's
the
some
standalone
runtime
stuff
and
the
rfc
for
extending
the
project
option
metadata
that
gustavo
just
threw
out
there
so
beyond
that
we'll
go
through
our
usual
introduction.
So
if
anybody
is
out
here
that
is
connected
and
new
to
the
community
that
would
like
to
introduce
themselves
to
everyone.
Now
is
the
time.
A
Going
once
going
twice
all
right,
I
don't
know
that
we've
got
any
announcements
or
news,
so
I
guess
it
kind
of
turned
everybody
in
the
audience.
Is
there
anything
they'd
like
to
highlight
or
talk
about
quick
news,
wise.
B
I
guess
one
thing
I
could
mention
is
that
we
merged
the
auto
tdm
support
for
micro
tvm
over
the
last
week
or
so
and
last
time
I
updated
the
docs.
So
there's
now
a
new
tutorial
to
show
you
how
to
do
that
on
docs,
tvmai
so
check
that
out.
If
you
guys
want
to
give
it
a
shot
and
there's
probably
a
couple
of
formatting
things,
we
need
to
fix
the
tutorial,
but
I
think
it
should.
It
should
run
so
cool,
okay,.
C
C
I
guess
this
came
up
from
the
fact
that
we
were
trying
to
use
just
a
wheel
to
deploy
something
for
microcontrollers
and
he
quickly
found
out
that
access
to
the
standalone,
crt
directory
itself
is
down
the
tvm
checkout.
So
you
have
to
build
it.
It
get
copied
there,
but
I
think,
there's
a
more
expanded
version
in
the
cdr
directory.
If
one
needs
to
find
true
but
and
if
we
kind
of
felt
it
would
be
useful
to
have
it
distributed
in
the
model,
every
format
so
just
wanted
to
hear
what
people
think.
B
Yeah,
I
have
a
couple
thoughts
on
that.
Actually
I
yeah,
I
think
I
actually
you're
right.
I'd
originally
put
that
in
the
model
library
for
my
proposal.
I
didn't
wind
up
implementing
that.
I
probably
didn't
explain
why
I
did
that
the
first,
I
guess
the
the
main
thought
that
I
had
was
that
you
know
if
we
want
to
think
about
the
model
library
format
as
kind
of
a
an
export
format
for
just
the
model.
The
runtime
is
not
really
it's
superfluous.
B
Basically,
over
that
what
I
had
been
thinking
about,
I
I
didn't
mean
to
remove
it,
though,
from
kind
of
like
downstream
consumers.
What
I
have
been
doing
in
project
api
was
basically
supplying
the
path
to
that
that
standalone
crt
tree-
and
I
guess
just
to
give
some
background
for
everyone
here
on
the
call
so
kind
of
to
match,
with
the
the
tbm
source
layout
we
have
like
the
you
know.
Tvm,
of
course,
has
two
runtimes.
B
It
has
the
c
plus
runtime
and
it
has
the
c
runtime
and
when
you
use
t
from
python
you're
using
the
c
plus
plus
run
time,
but
when
you
use
tvm
on
a
microcontroller
using
the
c
runtime
and
they're
different.
Basically,
the
c
runtime
sources
are
kind
of
what
we
want
to
make
available
to
downstream
from
our
projects
that's
kind
of
what
we
expect,
people
to
integrate
with
the
micro,
sorry,
with
micro,
tvm,
targeted
models
and
to
kind
of
align
with
the
tvm
source
tree
structure.
B
We
place
those
in
the
source
tree
under
src,
runtime
crt.
Along
with
this
the
c
run
time.
This
is
close.
Runtime
components
basically
comes
as
manupa
said,
when
you
try
to
use
this
as
when
you
are
building
things
or
when
you
have
the
tbm
source
tree
available.
B
You
know
in
in
theory,
you
could
just
pull
things
out
of
the
source
stream.
Now
I
kind
of
gotten
in
front
of
that
and
what
I've
done
to
address.
This
basically
is
as
part
of
the
tvm
build
system.
We
build
a
directory
tree
and
build
called
standalone
crt.
B
I
don't
know
if
I
should
share
screen.
If
that's
helpful
or
not,
but
basically
the
standalone
crt
is
intended
to
take
all
of
the
sources
that
are
included
in
the
tvm
source
tree
that
are
required
to
compile
this
c1
time
and
place
them
in
one
in
one
spot,
and
my
thought
here
was
that
we
could
actually
just
bundle
that
with
the
wheel
and
then
supply
that
separately,
basically
to
kind
of
downstream
users.
B
Currently
my
model
for
kind
of
people
using
things
I
guess
downstream
from
tvm,
is
that
people
would
write
product
api
implementations.
So
I
guess
one
question
I
had
for
you:
manupa
was
just
like.
Is
there
another
model
that
you
guys
were
thinking
about
using?
Should
we
should
we
make
another?
I
mean.
I
think
there
is
a
way
basically
there's
a
python
function
right
now
checked
in
called,
like
git
standalone,
crt
directory
under
my
under
tdm
macro.
B
Theoretically,
you
could
call
that
if
you
needed
to
supply
the
standalone
crt
to
some
some
downstream
user
outside
of
the
product
api,
but
I
was
curious
if
there's
another
way
you
wanted
to
deploy
stuff,
I
guess.
C
So
I
guess
our
concern
was
trying
to
enhance
a
single
command
experience
using
tvmc
compile.
So
this
sounds
to
me
like
an
additional
thing
that
you
have
to
run
to
get
the
path
or
the
directory
to
probably
for
the
downstream
integration.
C
While
I
mean,
if
you
get
the
model
library
format
through
tbmc,
compile
dash
dash
output
format
mlf,
it
felt
cleaner
to
have
everything
there.
I
mean
that
that
all
the
sources
in
there
has
to
be
reintegrated
to
the
project
anyway,
the
the
downstream
member,
an
application,
a
developer
in
in
a
deployment
scenario.
B
Yeah,
that
makes
sense.
Actually
you
know
what
this
this
might
be
interesting
to
talk
about
in
a
slightly
different
way,
because
actually
there's
another
there's
a
related
problem
that
I
think
I
was
curious
about
your
guys's
thoughts
on
the
other
type
of
external
source.
You
might
need
to
compile
a
model
library
format
archive
is
cmsnn
right
now,
because
if
you
happen
to
offload
an
operator
from
cmsnn,
we
don't
actually
include
cmsnn
with
the
model
library
format.
So
I
guess
you
know
I
I
guess
the
the
follow-on
question
there
is.
D
Yet
do
you
have
an
idea
at
the
moment
I
mean
we
are
including
this
as
part
of
the
feb
runner,
so
the
cmc
sentence
sources
are
coming
from
the
docker
itself,
as
in
docker
encompasses
that
so
yeah.
C
B
I
think
so
I
my
my
thought
is
that
it's
likely
there
will
be
quite
a
it's
likely
that
in
the
future,
we're
gonna
still
have
this
problem
of
like
requiring
some
external
library,
basically
to
be
used,
whether
it's
like
a
whether
it's
like
a
third-party
kernel
library
or
some,
some
math
library,
or
something
like
that-
that
has
more
optimized
math
for
teens
or
something
like
that
on
kind
of
undeployment
targets,
and
one
thing
I
was
thinking
we
should
probably
do
is
at
least
provide
some
indication
in
the
metadata.json
of
the
external
libraries
required
and
then
yeah.
B
E
Yeah,
I
so
so
if
you're
alone
just
a
comment,
I
think
there
are
slightly
different
cases
because
cm
season
and
if
somebody
is
sort
of
integrating
something
they
will
have
cm
season
end
within
the
project,
whereas
the
sort
of
tvmc
runtime
is
sort
of
part
of
tvm.
E
E
B
Right
right,
yeah
agreed
that's
sort
of
like
outside
of
product
api
and
all
that
yeah,
I
guess
to
some
degree.
I
think
that's
a
little
bit
of
a
convenient
situation
because
you
know
cmsis
contains
space
contains
basically
like
the
microcontroller
core
header
defines
basically
which
you
kind
of
need
anyway,
in
your
you
know,
final
project
along
with
these
nn
routines.
B
Basically,
whereas,
if
you
have
some,
you
know
purely
third-party
library
that
that
wasn't
integrated
with
the
the
core
header
files,
then
that
might
not
necessarily
be
true,
but
on
the
other
hand,
it's
kind
of
like
yeah,
if
you're
opting
into
using
one
of
these
libraries,
you
know
you
probably
are
expected
to
be
able
to
integrate
it
with
your
project
as
well.
So
there's
also
that
as
well.
B
So
what
I
am
suggesting,
though,
is
that
we,
we
should
add
standalone
crt
to
the
the
tlc
pack
wheel,
basically
like,
regardless
of
what
we
do
here.
I
think
you
couldn't
include
it
in
the
model.
Library
format,
unless
you
add
it
as
a
data
dependency
to
tlc
pack,
wheel.
E
So
there
is
the
there
is
the
other
pr
which
is
ongoing,
which
is
the
one
that
actually
adds
the
files
to
the
to
the
wheel
and
then
once
that
is
there.
So
there
is
the
minimal
infrastructure
for
us
to
implement
the
extensional
model
library
format
to
include
it
and,
of
course,
tbmc
will
get
it
by
default
kind
of
just
to
close
the
loop
on
this
end
user
use
case
right.
E
It
would
require
tvm
as
a
dependency,
whereas
if
we
have
the
the
artifact
that
comes
out
of
dvm
c,
it's
not
something
we
we
can
make
it
portable,
whereas
I
mean
there
is
no
really
other
dependencies
on
tvm
right
so
making
this
artifact
self-contained
would
be
improved
by
having
this
the
all
the
headers
it
references
as
part
of
the
turbo.
B
I
guess
the
tension
I
see
there
is
that
at
one
point
we
talked
about
promoting
model
library
format
to
handle
cases
outside
of
the
c
runtime,
and
actually,
I
guess,
sort
of
like
the
blocker,
for
that
is
that
if
you
have
a
byoc
library
that
generates
anything
besides
c
source
code,
we
don't
have
a
way
to
export,
basically,
the
the
generated
runtime
module
into
a
model
library,
format,
tar
and
but
if
we
solve
that,
and
since
we
kind
of
do
embrace
byoc
flow
for
for
micro
tbm,
it
sort
of
seems
like
we
should
address
it
anyway,
regardless
of
whether
it
becomes
a
sequels
plus
runtime
format
as
well.
B
If
we
solve
that,
then
we're
kind
of
looking
at
model
library
format,
as
kind
of
a
like,
I
guess,
to
kind
of
back
up
to
probably
I
should
have
just
started
by
saying
this.
The
the
tension
I
see
is,
like
is
model
library
format,
a
a
cell,
a
format
that
contains
the
generated
model
sources.
Or
is
it
a
self-contained.
B
I
think,
like
personally,
I
was
kind
of
thinking
of
it
more
as
the
the
former
rather
than
than
the
latter
in
particular,
because
if
we
push
it
towards
like
something
that
could
be
useful
for
the
people's
plus
run
time,
I'm
not
sure
that
we,
we
just
have
to
think
a
lot
more
about
like
what
it
means
to
be
a
self-contained
thing.
I
guess
like
in
the
sql
source
runtime.
We
still
depend
on
tbm
to
do
things
like
launch
gpu,
compute,
and
things
like
that.
E
B
I
think
the
missing
piece
there
is:
we
would
need
to
define
a
baseline
compilation
flow
that
builds
a
shared
object
that
could
be
loaded
through
the
library
into
the
cv
into
the
simplest
runtime.
I
don't
think
we're
doing
anything
to
circumvent
that
right
now,
but
I
don't
think
that
I
think
that
that
is
a
big
change.
B
I
agree
and
in
particular
a
lot
of
the
interesting
things
in
the
peoplesoft
runtime
are
well
there's
many
use
cases,
but
a
major
use
case
that
we
couldn't
ignore
in
the
people's
quest
running
time
is
targeting
gpus
when
you
target
a
gpu.
B
What
we,
what
we
get
out
of
the
compiler
currently
is
this
runtime
module
that
contains
like,
for
example,
cuda
sources,
and
so
what
we
don't
have
is
a
way
to
like
programmatically,
walk
those
runtime
modules
and
assign
basically
those
cuda
sources
to
a
file
name
under
the
model.
Library
format,
tar
right
now,
and
so
there
isn't
basically
a
way
where
we
could
offer
like
a
standard
path
structure.
For
that
I
I
so
anyway,
there's
just.
E
So
so
then
an
option
would
be.
I
mean
just
to
come
back
to
the
original
original
use
case.
What
if
we
use
that
manifest
file
to
kind
of
describe
what's
in
that
package,
and
then
we
include
the
standalone
syrian
time
as
an
optional
that
can
be
there
or
can
not
be
there,
and
you
can
query
that
elegantly
on
the
manifest
file.
You.
B
Mean
is
you
talking
about
the
metadata.json
or
yeah?
We
could
do
that
so
so
that's
one
thing
I
was
thinking
about
and
and
kind
of
the
reason
I
was
bringing
up
the
cm
system.
Thing
too
was
like
I'd
like
to
have
a
way
of
of
talking
about
kind
of
libraries
that
you
need
to
integrate
into
this
project
in
order
for,
in
order
for
you
to
build
it
and
so
yeah
the
libraries
could
live
inside
the
model,
library
format
tarball.
If
we
wanted
them
to
that's,
that's
certainly
possible.
B
B
That
kind
of
a
thing
I
did
like
a
an
initial
implementation
just
on
this
internal
product,
api
implementation,
where
we
integrated
one
of
the
cms
cnn,
we
integrated
with
the
cmsis
and
then
package
basically
to
support
our
schedules
to
support
the
the
arm
schedule
we
have
checked
in,
and
you
know
what
we
do
for
that
right
now,
basically,
is
like
grep
for
includes,
I
think,
and
so
like
look
at
the
output,
look
at
the
generated
c
files
and
look
for
includes,
and
so
I'd
like
to.
B
I
would
like
to
find
a
better
way
than
then
like
manually
scanning.
The
generated
c
codes,
for
you
know
include
our
math.h
or
something
like
that,
determine
whether
or
not
we
need
to
link
against
that.
So
it
could
be
something
like
we
have
like
a
mapping
from
library
name
to
path
or
something
like
that.
If
we
wanted
to
do
something
like
that
or.
E
Yes,
so
I
I
was
thinking
about
about
the
kind
of
the
differences
between
this
specific
case.
We
are
talking
about
the
standalone
syrian
time
and
the
other
cases
you
mentioned,
and
I
think
the
main
difference
that
I
got
from
those
is
that
in
the
other
environments,
like
the
one
you
said
with
gpu
and
the
one
you
said
with
the
c
plus
plus
runtime.
E
The
majority
of
this
is
that
correct
to
assume
that
they
will
need
to
have
tvm
installed
anyway
and
they
can
host
the
tvm,
because
it's
a
host
a
hosted
system.
B
B
You
could
change
that
to
consume
model
library,
format
and,
and
there
could
be
a
gp
like
there
could
be
cuda
source
code
in
there
and
you
could
build
basically
a
static
binary
from
that
which
would
invoke
computation
on
a
gpu,
but
it
would
depend
on
a
pre-link
like
a
pre,
basically
depend
on
on
the
cuda
package,
basically
being
available
on
the
system,
so
there
is
some
sort
of
like
downstream
linkage
required.
B
I
guess
if
that
makes
sense
and
right
now
the
way
we
handle
that
is
we
handle
that
at
the
tv
and
build
time.
So
when
you
build
tvm,
it
looks
for
all
those
required
libraries
at
that
time,
whereas
if
you
were
to
use
this
kind
of
bundle
deploy
methodology,
you'd,
probably
you
would
sort
of
move
that
up
to
to
the
point
in
time
when
you're
consuming
the
model
library
format.
So
basically,
I
think
I
would
kind
of
summarize
it
as
like
you.
B
It
still
has
the
commonality
of
requiring
some
external
library,
but
the
question
is
basically
like:
does
the
user
supply
that
library
or
do
we
supply
that
library,
with
with
model
library
format
and.
B
C
Runtime
modules,
so
what
the
compiler
does
it
packs
the
binary
artifact
into
the
so
and
which
the
runtime
entangles
and
creates
right.
So
I
feel
still
the
model
library
format
could
be
that
interchangeable
format
from
the
compiler
to
the
runtime.
But
in
this
particular
case
of
the
micro
deployment
scenario,
standalone
crt
seems
just
a
missing
piece
to
get
the
model
level
format.
Compilable.
Even
the
target
is
probably
a
firmware
image.
That
is
one
compilation
right.
B
Right
yeah,
I'm
sort
of
like
I
think
that
the
the
main
drawback
I
see
with
putting
well,
I
guess
the
drawback.
I
see
the
immediate
drawback
I
see
was
putting
the
model
library
format.
Sorry,
the
standalone
crt
in
the
model,
library
format
is
compilation,
time
or
or
sorry
tarball
size.
Basically,
if
we're
sort
of
expanding
past
this
minimal
representation
of
the
the
generated
code,
and
but
I
see
your
point
about
backwards,
compatibility
and
kind
of
like
encapsulating
kind
of
the
required
dependencies.
B
I
guess
I
still
think
you
have
that
problem
with
cmsis
and
n
to
some
degree
as
well.
Like
there's
kind
of
a
question
of
like
I
think
I
asked
this
when
we
were
first
talking
about
the
same
system,
integration
which
is
like
to
what
degree
do
we
want
to
bind
tvm
to
a
particular
cmssnn
version
and
so
yeah?
There
is
still
some
like
in
particular,
where
you
might
see
that
is,
if
we
ever
generate
calls
to
cmsnn
through
the
lvm
back
end.
You
know
that
would
require.
B
It
basically
means
that
we
have,
to
you
know
correctly
model
all
the
header
files
in
in
tbm
in
order
to
generate
kind
of
the
required
call
signature
on
the
stack.
So
I
guess
I
I
I
I
don't
disagree.
This
helps
like
I.
I
definitely
think
including
it
in
model.
Library
format
solves
at
least
this
one
problem,
I'm
wondering
if
it
if
it
solves.
B
Basically,
I
guess
what
I'm,
what
I'd
at
least
like
to
do
is
make
sure
there's
a
way
that
we
address.
The
the
broader
problem
of
here
are
the
external
libraries
that
you
require
and
here's
the
version
we
think
you
should
should
have
for
standalone
crt.
It's
pretty
much,
always
the
same
version
that
is
included
with
cbm
that
produce
the
wheel.
Then
it
could
be
something
very
different.
You
know.
E
There
is
another
thing
which
I
think
is
important
in
this
case,
which
is
supposing:
supposing
we
don't
do
it,
the
user?
Will
they?
When
the
user
compiles
their
binary,
they
will
see
an
error
that
there
is
a
there.
Is
a
header
missing
and
this
header
what
you
need
to
do
to
obtain
this
header
is
not
some
kind
of
it's.
Not
it's,
not
a
simple
process.
You
need
to
clone
your
tvm
repository.
B
Yeah
I
mean,
I
guess,
the
the
point
being
that
the
tbm
repo
is
way
bigger
than
the
same
system
and
but
but
sorry,
but
if
we
include
the
cm6n
library
as
a
data
dependency
in
the
wheel.
Sorry,
we
include
sorry
I'm
getting
my
terms
mixed
up
here.
If
we
include
standalone
crt
as
a
data
dependency
in
the
the
tlc
pack
wheel,
can't
you
just
copy
it
off
of
the
disk.
E
Yes,
you
can
you
need
to
do
some
some
magic
in
there
to
find
what
it
is
that
will
probably
bury
it
deep
into
your
dependencies.
It's
it's
not
like
readily
yeah,
and
also,
I
think
you
would
need
to
guarantee
that
that
specific
one
you
got
is
compatible
with
the
things
you
generated.
I
know
that
that
changes
very
rarely,
but
in
this
case
I
think
this
is
relevant.
E
B
E
E
E
The,
but
there
is
one
thing
I
think
it
could
close
that
case
is
that
we
could
make
it
optional
so
that
if
the
user
doesn't
want
it,
it
won't
take
that
space.
But
I
think
it
is
a
very
useful
feature
in
that
embedded
use
case.
B
Yeah,
I
I
agree
that
well
so
I
I
definitely
think
that
that
whatever
we
do
here,
it
needs
to
be
easy
to
get
a
hold
of
standalone
crt
and
it
needs
to
be
easy
to
get
a
hold
of
the
standalone
crt
that
is
compatible
with
the
the
model
library
format,
tar
that
that
is
generated,
and
one
thing
like
where
that
can
be
difficult
is,
if
you
you
know,
if
you
generate
the
model
library
format,
and
then
you
forget,
which
version
of
tbm
you
had
installed,
and
then
you,
you
know
if
you
reinstall
it
or
or
or
whatever
you
know,
someone
else
generated
it
and
you
don't
have
that
copy
anymore.
B
B
Yeah
I'd
kind
of
built
this
function
here
just
I'll,
show
this,
and
then
I
can
stop
sharing
my
screen.
I
kind
of
built
this
function
here
to
kind
of
point
to
the
standalone,
crt
directory
and
kind
of
the
thought
I
had
originally
when
I
was
doing
it
was
that,
like
tbmc,
could
either
print
that
path
or
project
api
when
you
call
generate
project
includes
that
path
as
an
argument.
B
Basically,
so
I
kind
of
thought
about
supplying
it
kind
of
externally
to
the
model
library
format,
to
avoid
complicating
the
tar,
I
do
think
we
should
probably
make
well,
I
sort
of
think
we
should
make
a
a
single
choice
here.
Rather
than
have
two
options
just
because
then
then
it
kind
of
complicates
the
downstream
user
workflow,
because
you
know
someone
could
write
like
a
how
to
you
know,
use
model
library
format
and
like
assume
that
someone
provided
the
standalone
crt
as
part
of
that
model
library
format.
B
And
then
you
know
if
in
fact
that
wasn't
done,
then
this
how-to
would
be
invalid
and
people
would
get
confused.
So
I
do
think
we
should
make
one
choice.
There.
C
Just
a
few
points
to
add
here
is
one
thing
is
that
I
should
have
said
this
a
bit
before
the
main
distribution
is
the
channel.
Crt
sources
are
part
of
tbm,
so
I
think
we
should
make
it
clear.
It's
an
internal
thing
compared
to
cmc
species
external,
and
the
latter
part,
is
that
so
in
order
to
build
the
firmware
image,
they
need
to
have
the
exact
version
of
tvmc,
especially
if
the,
if,
if
it
goes
from
one
developer
to
another,
partially.
C
B
I
I
guess
the
only
so
you
know
my
only
hesitation
here
is.
I
would
also
like
to
solve
this
for
the
kind
of
external
library
case
as
well
like
as
if,
let's
imagine
we're
in
this
case,
where
we're
transferring
the
model
library
format
from
one
developer,
who
ran
to
vmc
to
the
other
developer,
who
is
consuming
it?
How
should
the
downstream
developer
know,
which
version
of
of
steam
system
to
use
as
well
or
like
how?
How
should
they
know,
which
version
is
required?
Basically,.
B
B
To
some
I
mean
if
cmc
were
not
a
version
release
product
like
a
project,
I
could
probably
also
say
the
same
thing
about
that
right.
So
I
kind
of
think
that
the
the
question
of
how
you
obtain
this,
the
stanley
crt
directory,
is
a
little
bit
separate
from
how
we
document,
which
version
is
required,
basically
in
the
model
library
format.
Tar.
B
It
seems
a
little
bit
like
if
you're
gonna
generate
code
that
requires
on
it
requires
an
external
thing
or
some
other
third-party
sorry,
some
other
c
code.
We
should
at
least
say
which
dependency
for
for
mlf,
sorry
for
standalone,
crt,
that's
actually
quite
simple.
We
just
put
the
build
build
sha
of
the
the
tvm
binary
as
the
revision
required
until
we
do
a
release
and
then,
of
course,
we
have
to
put
the
release
version
or
something
like
that.
C
B
Right
well,
the
question
is,
you
know,
one
thing
is
like:
would
they
be
conscious
of
that
or
would
we
automatically
enable
like
cssmsn
offloading.
C
B
D
D
So
as
such,
there
is
no
versioning
right
out,
but
I
mean
this
question
will
definitely
come
up.
I
mean
later
on
when,
when
we
move
away
from
the
test.
B
Right,
I
mean,
I
think,
like
right
now,
you
know
if
we're
talking
about
sort
of
ci
unit
tests,
we
kind
of
sidestep
the
problem,
because
we
pretty
much
like
kind
of
we
kind
of
design
ourselves
to
be
a
little
bit
loose
on
the
versioning
side
there,
so
that
we
always
kind
of
pull
the
latest
cmsn.
And
so,
if
there's
a
change
in
in
the
the
tip
of
cm
cis
and
n,
we
we
see
that
right
away,
and
so
we
kind
of
see
that
as
a
unit
test
failure.
B
We,
like
decrease
the
robustness
of
the
unit
tests
in
favor
of
of
making
sure
that
we're
always
kind
of
like
maintaining
compatibility
with
head,
whereas
in
your,
if
you're
kind
of
like
in
a
production
or
release
situation,
you
probably
want
to
at
least
document
the
the
required
version
of
seems
to
send
in
or
the
expected
version
anyway.
D
Yeah
so
far
I
mean
in
the
non-micro
world.
How
does
it
happen
with
other
library
integrations
the
versioning.
B
D
B
You
know
I
I
I
don't
want
to
say
that
I
can
100
speak
for
everyone
else,
because
I
have
not
used
the
non-micro
stuff
nearly
as
much
as
I
probably
should
to
to
answer
this,
but
I
think
it's
pretty
pretty
undocumented
and
you
might
look
to
like
the
ci
build
scripts
or
something
like
that
to
figure
out
which
version
of
kudo
we
test
against.
B
One
thing
I
know
is
that,
like
some
of
the
operators
outside
of
from
the
operators
that
we
use
in
kind
of
a
traditional,
cpus
plus
front
dbm,
runtime
land,
they
actually
invoke
pact
funks
as
their
kernels
and
the
packed
funk
calls
out
to
a
downstream
python
library
or
downstream
sql
spouse
library,
and
at
least
on
the
python
side.
Right
now
you
know
we
don't
really
capture
our
dependencies
very
well,
so
you
know
that's
the
story
is
not
very
good.
There
basically
doesn't
mean
we
should
shouldn't
improve
it.
B
Yeah
yeah,
no,
no,
it's
not
it's
not
great
one
difference
there
is
that
in
you
know,
in
the
in
the
siebel
special
one
time
case,
tbm's
both
generating
and
consuming
the
the
artifact
in
most
cases,
so
it's
sort
of
like
use
the
same
version
of
tbm
to
some
degree.
I
think
or
use
the
same,
build
of
tbm
and
then
that
that
solves
that
problem.
I'm
sure
there
are
cases
where
someone
has
to
use
a
slightly
different,
build
and,
and
they
see
issues
I
wouldn't
be
surprised.
B
If
that
happens
so
yeah
one
thing
is
like
maybe
it's
possible
that
we
could.
I
mean
I've
been
thinking
about
this
a
little
bit
and
and
like
in
the
ci
we
currently
like.
We
prefer
packages
to
float
to
latest
version
similar
to
what
we
were
talking
about
with
kind
of
how
we
integrate
with
cnn,
and
it
might
be
that,
like
as
we
get
to
the
point
of
cutting
release.
B
Maybe
we
prefer
to
test
against
a
particular
like
revision
of
cmss
and
like
a
release
version
basically
and
then
somehow
document
that
in
the
tvm
side,
like
state
that
we're
going
to
take
the
last
major
or
I
guess
last
full
release
of
team
ssnn
and
then
pull
that
tag.
Basically
in
our
pre-release
tests
for
testing
and
then
and
then
maybe
the
tlc
pack
wheel
could
say,
here's
that
version
of
seems
and
then
that
I
was
at
least
you
know,
tested
against.
B
Basically,
presumably
there's
some
backwards
compatibility
policy
with
cm
system
that
users
could
could
kind
of
consult
if
they
wanted
to
upgrade
or
downgrade.
D
Yeah,
that
sounds
like
a
good
idea
that
would
also
entail
that
we
need
not
include
the
cmc
n
sources
directly
into
mls
right.
D
B
That
sort
of
ties
that
up
because
yeah
the
only
argument
for
including
them
is
basically,
if
we
didn't
have
that
and
so
like
then,
which
version
did
we
we
care
about?
And
I
I
personally
think
that
we
should.
I
sort
of
my
opinion
is
to
try
to
keep
things
as
as
minimal
as
possible
in
model
library
format.
But
you
know
okay,
so
so
having
discussed
that
then-
and
you
know,
we
should
propose
this
and
all
that
with
sort
of
an
rfc
to
to
some
degree,
or
at
least
some
some
forum
written
thing.
B
B
You
know
things
change
fairly
drastically,
and
so
how
do
we
pin
down
that
version?
One
easy
way
is
to
just
include
it
in
the
tar.
B
I'm
curious
a
little
bit
to
see
how
you're
intending
to
call
like
the
tvmc
compile.
Is
this
like
from
a
make
file
or
is
this?
Is
the
the
flow
more
like
imagine
developer
a
you
know,
generates
a
model
library
format
and
passes
it
along
to
developer
b.
I
guess
I'm
just
wondering
if
there's
some
sort
of
like
codified,
build
steps
that
you're
thinking
about
having
done
like
automatically.
E
Or
I
think,
as
a
as
a
flow,
it
would
be
more
like
a
tvmc's
part
of
your
make
file
and
or
you
have
that
model
generated
with
tbmc
and
you
archive
that
somehow
within
the
project
right,
I
I
mean,
as
we
don't
release
the
standalone
runtime
as
something
that
the
user
can
see
and
we,
I
don't
think
we
ever
done
that
in
tvm
right,
I
think
yeah
still.
I
think
it
would
be
beneficial
to
have
that
and
I
don't
think
the
cost
is
very
high,
because
those
those
files
are
not
not
very
big.
E
B
A
So,
a
bit
of
a
time
check,
we've
got
one
more
thing
on
the
agenda
and
we're
down
to
probably
about
10
15
minutes
left
in
the
session.
Do
we
want
to
keep
going
on
this
topic,
or
what
do
you
guys?
Everyone
think.
B
Yeah,
let's,
let's
talk
about
the
project
option
thing,
but
I
I
I
see
where
you're
coming
from
android
manuba,
so
maybe
we
can
follow
up.
I
think
I
think
these
are.
E
B
Concerns
you
guys
are
presented
so
so
maybe
we
can
follow
up
on
the
discuss
forum
or
something
like
that
or
or
even
next
meet
up
as
well.
I
just
need
to
think
a
little
bit
more
about.
B
I
will
have
to
change
project
api
a
little
bit
and
which
is
fine,
but
I'm
kind
of
wondering
a
little
bit
like
if,
if
there
is
already
this
automatic
make
flow
like,
is
it
any
different
if
we
just
make
a
command
or
or
some
or
have
some
way
of
looking
up
the
locally
built
thing.
E
B
F
No,
I
can't,
I
think
I
can
make
it
fit
in
like
10
minutes,
so
there
is.
There
is
enough
time
to
go
through
it.
It's
not.
It's
actually
quite
simple.
It's
more
to
also
make
the
community
aware
of
the
rfc
which
is
under
reveal,
so
I
can
go.
B
In
why
don't
we?
Why
don't
we
give
some
time
to
gustavus?
Do
that
and
I
feel
like
I
just.
I
need
to
think
a
little
bit
more
about
this,
because
I
I
get
what
you're
saying
you
guys,
but
I'm
still,
I'm
not
100
convinced
that
we
can't
work
around
it
in
other
ways
as
well.
F
Sorry,
you
are
talking
about
the
model,
library
format
or
about
sorry.
B
Yeah,
I
just
I
just
sort
of
buttoning
that
up
yeah.
What
do
you
want
to
talk
about
this
product
option
thing
for
ten
minutes
or
something
like
that?.
F
Yeah,
if
you
are
okay
but
whatever
is
it,
is
it
okay
for
you,
I
mean
to
go
for
it
in
time.
F
That
yeah,
okay,
so
so,
as
some
of
you
know,
I've
we've
been
working
on
adding
support
for
micro
targets
on
tvmc
and
were
there
was
a
an
old
version
rfc
for
doing
that
which
didn't
use
the
project
api
contributed
by
octaml.
So
I
started
to
work
on
a
new
one
using
the
project
api
and
I
did
a
prototype
which
I
kind
of
presented
most
of
it
in
a
demo
a
couple
of
meetups
ago
and
when
finishing
that
prototype,
which
uses
the
project
api.
F
I
realized
that
some
some
information.
F
For
the
new
micro
contacts
on
tvmc,
so
this
is
so
the
the
rfc
is
pretty
much
about
that
about
adding
new
metadata
to
the
existing
options
in
a
project
because
currently
project
api
will
return
the
options,
but
they
the
options,
won't
allow
things
like
determining
the
methods
from
the
api,
the
api,
where
the
options
can
be
used.
F
So
just
let
me
quickly
share
the.
F
Can
you
see
my
my
screen
yep,
you
can
okay,
so
so
the
motivation
is
basically
about
using
the
project
api.
F
Options
which
are
returned
by
a
info
query,
so
there
is
a
way
to
request
to
the
project
api,
the
options
available
for
a
given
given
platform,
and
now
we
have
zephyr
and
arduino
platform,
for
instance,
which
have
different
options
for
for
the
methods
which
are
like
meant
to
build
flash
and
run
a
model.
F
So
the
rfc
is
basically
proposing
a
way
to
first
thing
to
discover
which
for
a
given
option,
which
methods
it
it
can
be
used
and
if
it's
required
or
not,
because
if
that
data,
that
information
is
not
available,
what
happens
is
that
on
tvmc?
F
We
will
need
to
keep
a
table
repeating
the
options
available
in
a
platform
and
saying
which
one
is
require
required
or
not
in
order
to
build
the
parser.
So
this
is
quite
gets
quite
complicated
on
tv
tvmc
side.
So
this
rfc
is
so
proposing
these
two
metadata,
which
is
required
an
option
which
are
pretty
much
just
a
list
of
the
methods
where
the
option
which
has
those
metadata
associated
to
can
be
applied.
F
And
another
thing
is
that
some
of
the
options
like
verbals
option
can
be
converted
directly
to
a
flag
into
when
we
are
using
a
command
line.
Interface
tool
like
tvmc,
and
currently
there
is
no
way
to
determine.
If
a
option
is
what
time
or
type
it
is,
if
it's
a
boolean,
for
instance,
in
the
case
of
the
verbose
option.
F
So
we
could
like
there
is
a
field
in
the
metadata,
which
is
choices
which
we
could,
for
instance,
for
the
boolean
type,
like
verbose
option,
return
a
tuple
of
true
and
false.
But
this
will
you
know.
F
Add
the
complication,
it
is
also
cumbersome
to
iterate
through
the
tuple
tuple
and
looking
for
the
false
and
true
object
so
which
would
be
cause
a
cumbersome
code
on
tvmc
side.
Where
and
on
the
other
hand,
it
could
be
promptly
provided
by
the
api.
F
So
this
rfc
is
also
proposing
adding
a
type
field
which
will
say
explicitly
what
type
the
option
is,
and
so,
if
it's
a
boolean
a
string,
an
end
or
a
float,
for
instance,
and
the
rfc
is
also
saying
which
option
is
mandatory
or
not,
and
in
in
that
case
type
it
would
be
provided
for
every
option
and
will
be
mandatory
in
that
sense.
F
So
so
it's
not
optional
and
the
last
one
is
the
last.
The
last
one
is
about
the
default
value
accepted
by
a
given
option,
and
it
happens
that
not
every
option
needs
to
define
it,
since
it
doesn't
make
sense
to
every
option.
So
this
is
a
field
which
is
meant
to
be
optional
in
case
the
api
already
has
a
default
value.
F
This
will
also
easy
the
use
of
project
api
to
build
the
parser
on
tvm
c
side,
and
this
is
actually
a
quite
low
impact
change,
because
it
pretty
much
consists
in
expanding
the
fields
the
members
available
in
the
up
project
option
class,
which
is
under
the
hood,
a
name
it
tuple.
So
this
will
once
if
that
rfc
gets
accepted,
all
that's
necessary
to
to
change.
F
The
current
code
is
to
implement
for
the
currently
available
options
in
each
project,
so
on
zephyr
and
arduino,
they
will
have
to
implement
the
required
method,
metadata
method
data
been
added
by
the
rfc,
which
is
quite
straightforward,
so
they
will
need
to
provide
the
optional,
for
instance,
here
there
is
a
case
for
extra
file
start.
F
This
is
for
zephyr
only
so
it
doesn't
apply
for
arduino
platform,
for
instance,
so
via
the
through
the
project
api,
the
user
can
request
which
options
are
available
and
the
extra
underline
files
on
the
learn.
F
Tar
option
is
one
of
the
options
available
and
after
the
rfc
is
accepted,
we
would
need
to
provide
a
optional
list
of
the
project
of
the
methods
of
the
api
which
accepted
that
option
extra
file
star,
which
in
that
case
is
the
generate
project
which
is
used
on
tvmc
on
the
create
project
subcommand,
it
is
necessary
to
provide
an
optional
or
a
required
list
by
either
or
both,
but
at
least
one
must
be
provided.
F
So
that's
it
so
pretty
much.
The
rfc
in
summing
it
up
is
about
adding
four
new
fields
to
the
metadata
associated
to
a
option
returned
by
the
project
api
for
the
platforms.
F
So
that's
I
please
comments
concerns.
I
would
be
happy
to
hear
about
it.
That's
what
I
would
like
to
share
about
these
rfc
it's
under
reveal.
So
please,
if
you
want,
go
there
and
put
your
comment.
B
Yeah
thanks
so
much
for
the
overview
here
and
yeah.
I
mean
like
to
encourage
everyone
to
kind
of
take
a
look
at
the
rfc.
I
feel
like
we're
two
minutes
to
time
here,
so
I
don't
want
to
run
the
meeting
too
far
over.
If
anyone
has
any
quick
comments,
I'm
happy
to
to
discuss
them
here,
but
but
you
know,
as
always,
we're
we
like
to
write
down
all
decisions,
and
so
also
please
do
consult
the
rfc
as
well
and
and
comment
there.
F
Was
that
more
or
less
what
you
had
in
mind,
andrew
after
our
discussion
about
it.
B
Yeah
yeah,
I
think
I
think
in
general
that
seems
fine.
We,
because
I
wanna
discuss
this
a
little
bit
when
you
ran
into
the
problem
of
trying
to
figure
out
which
options
how
to
how
to
present
the
required
project
options,
basically
to
to
the
user
and
yeah,
I'm
generally
supportive
of
it.
I
think
that
it
would
be
good
to
you
know.
One
thing
is
I
don't
want
this
what's
wrong.
B
I
I
think
one
thing
is
that
it'd
be
good
to
to
make
sure
that
just
think
about
the
ways
to
enforce
that
product.
Api
implementations
might
use
this,
and
the
other
thing
is.
I
am
a
little
bit
wary
about
making
this
interface
so
rich
that
people
kind
of
build
this
secondary
protocol
on
top
of
our
project.
B
Api
implementation
and
sort
of-
I
guess,
make
things
more
complicated
here
than
they
they
need
to
be,
but
a
lot
of
these
options
are
motivated
by
kind
of
generating
projects
that
work
for
for
auto
tuning,
and
so
I
think
that
does
serve
as
like
a
minimal
driving
use
case
here.
So
overall
I'd
say:
yeah
the
rfc.
It
looks
pretty
good
and
I'll.
Take
a
look
at
it
today
so.
F
A
All
right
all
right!
Well,
thanks
everyone
thanks
for
all
the
discussion,
I
think
we're
at
the
top
of
the
hour,
so
I
think
we'll
go
ahead
and
close
today's
meeting
once
again,
thanks
for
all
your
participation
and
we'll
see
you
in
approximately
two
weeks,
thanks
everyone
bye-bye
thank
you.