►
From YouTube: 2022-07-26 - Diagnostics WG meeting
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
Okay,
we
are
live.
Welcome
everybody
to
the
diagonal
working
group
meeting
before
gets
get
started.
Does
anybody
have
any
announcement.
A
I
don't
think
so.
Okay,
so
let's
jump
to
the
first
issue
in
the
agenda,
I
will
share
the
minutes.
Right
here
is
the
alternative
to
ll
node.
A
B
The
bits
and
pieces
yeah
the
agenda
right:
okay,
yeah,
so
basically
this
is
an
item
that
kevelki's
erased.
In
terms
of
do
we
want
to
investigate
and
using
some
different
internals
debug
helper
fundamentally
within
v8,
in
order
to
generate
or
understand
what
the
contents
of
a
core
dump
are.
B
Okay,
I
think
given
where
we
are
with
maintaining
compatibility
with
the
internals
of
v8.
I
think
that's.
It
makes
a
lot
of
sense
to
investigate
it
and
I'm
I
haven't
even
had
a
chance
to
look
at
the
documentation.
That's
already
been
provided,
so
I
have
no
opinion
on
it,
but
sort
of
there
was
sentiment
within
the
original
post
was
oh,
it
seems
like
we're
going
to
continue
with
ll
nodes.
So
there's
no
point
in
investigating
this,
and
I
don't
quite
see
it
that
way.
B
I
think
if
we
have
something
that's
going
to
be
more
maintainable,
that
more
people
can
collaborate
on.
I
think
that's
a
very
worthwhile
worthwhile
thing
to
investigate.
So
what
I,
what
I
put
in
the
when
I
put
in
the
issue,
was
that
I'd
have
a
read
and
then
circle
back
and
and
think
about
how
we
can
potentially
stand
this
up.
B
I
know
we've
there's
precedence
in
node
for
just
standing
upside
projects
and
thinking
about
udc
and
a
number
of
other
things
where
they
start
off
as
experimental
and
sort
of
as
they
mature
we
migrate
towards
them.
I
just
don't
know
how,
given
the
limited
number
of
folks,
we
currently
have
in
sort
of
the
post-mortem
area,
how
achievable
that's
going
to
be,
but
I
think
at
least
technically
validate
it.
It's
that
I
think
that's
the
next
step
or
have
a
conversation
around
it.
What
did
it
look
like
technically
what
needs
to
be
done,
etc,
etc?
B
So
that's
my
plan
with
it,
so
I
was
hoping
I
I
was
hoping
that
folks,
who
are
interested
in
portsmouth
more,
would
be
able
to
join
this
call.
But
if
not,
then
I'll
set
something
specific,
it
was
a
postmortem
working
group
back
in
the
day.
I
think
I'll
set
something
up
specifically
just
to
dive
into
some
of
the
detail
of
that.
B
If
folks
can't
make
this
general
diagnostics
call
it,
it
might
make
sense
just
to
kick
it
off
as
a
specific
post-mortem
call,
but
yeah
the
the
four
people
on
the
issue
and
that
have
expressed
an
interest
in
it
yeah
and
get
them
on
and
take
it
from
there.
Yeah.
A
Yeah
that
sounds
reasonable.
To
me
I
mean
I
think
that
would
be
great
to
have
an
issue
showing
the
next
steps
of
the
ll
node
for
the
for
the
folks
who
is
willing
to
to
contribute,
and
also
I,
I
think
that
it's
worth
it
to
mention
it
in
every
diagnostic
working
group
meeting
just
to
to
keep
tracking
off
this
to
not
let
this
issue
in
the
limbo.
A
You
know
so
actually,
honestly,
I'm
interested
to
help
on
this,
but
I
nowadays
I
don't
have
bandwidth
to
to
deal
with
the
current
the
current
task
list.
So
if
we
have
just
a
tracking-
and
it
would
be
awesome
to
to
to
work
on
that
whenever
I
have
time
or
other
folk
have
time
as
well,
I
believe
steven
also
is
interested
in
helping
on
that
right.
C
Yeah
yeah
I'm
interested
in
trying
to
contribute
to
ll
nodes
as
much
as
I
can.
A
B
Yeah,
so
is
that
how
you
want
me
to
do
it
and
raise
an
issue
in
diagnostics
and
llo
tracker
and
it's
kind
of
what
I
started?
Was
it
the
issue?
Fifty
five,
seven
one.
I
think
it
was
a
five
seven
one
wasn't
it.
I
started
just
put
some
like
tracking
notes
in
there.
I
think
yeah,
yeah
yeah,
so
I'll
move
that
out
into
a
separate
issue
and
yeah.
B
Let's
have
that
as
a
tracker,
because
there's
of
course,
as
well
as
the
sort
of
the
the
elephant
in
the
room
which
is
sort
of
the
getting
16
compatible
and
there's
all
the
pieces
like
the
ci
like
llvm,
like
abi
compatibility,
blah
blah
that
needs
to
be
monitored
and
and
there's
other
there's
other
pieces
as
well.
That
need
to
be
that
we
need
to
give
updates
on
so
yeah
yeah
right
and
the
roadmap
again
around
whether
we
want
to
use
debug
help
or
whatever.
B
C
Yeah,
mainly
the
the
stuff-
that's
like
I
personally
want
to
know
is
like
what
what's
the
state
of
the
world
now
and
what
are
like
the
ongoing
maintenance
tasks
going
to
be
like
I,
I
know
there's
like
like
changes
between
major
versions
like
it.
It
would
be
nice
to
have
to
have
like
a
process
in
mind
of.
Like
oh
yeah,
like
when,
when
this
new
major
comes
out,
you
should
look
at
like
these
particular
places
to
figure
out
what
needs
to
change.
C
B
Yeah,
so
a
few
years
back,
I'm
going
to
say
between
12
10,
12,
14
versions
of
node,
I'm
just
definitely
saying
between
10
and
12,
the
core
folks
used
to
emanate
what
was
changing
v8
to
the
different
projects,
and
we
get
the
heads
up
from
core
that
these
changes
are
coming
down.
Therefore,
it's
going
to
and
it's
going
to
impact
these
types
of
things
and
then
they'd
be
picked
up
and
worked
on
et
cetera,
et
cetera.
So
this
that's
historically
how
it's
worked,
but
I
don't
know
if
that's
still
in
place.
B
C
Yeah
yeah,
I'm
I'm
relatively
involved
in
v8
stuff
external
to
node,
so
it
would
make
sense
for
me
to
get
more
involved
in
that.
If
there's
like
a
channel
for
that
to
happen,
yeah.
B
Yeah
so
I'll
find
out
because
it
definitely
did
happen.
I
was
going
through
the
some
of
the
previous
issues
and
again
to
try
and
track
down
what
what
types
of
changes
is
exactly
the
question
you
asked
actually
and
so
yeah
and
I'll
find
out
who
was
on
those
and
what
groups
they're
in
and
yeah,
put
some
shape
on
that
as
well.
Okay,.
A
Great,
the
next
one
in
the
agenda
is
re-evaluate,
ebp
apps
tracing
tool
list.
Basically
this
one
I'm
still
investigating.
Yesterday
I
did
a
quick
look
and
to
to
see
how
can
we
include
usd
probes
to
the
node.js
core?
Currently
we
have
we
have
a
static
trace
for
http.
A
A
The
future
of
monitoring
node.js
without
overhead,
at
least
usually
most
of
the
the
tracers
most
of
the
monitoring
node.js,
I
add
at
least
20
percent
of
overhead
on
top
of
the
application.
So
I
believe,
if
you
have
it
in
your
abpf
kernel
in
the
kernel
slide,
I
believe
it
will
be
way
less.
B
Yeah,
so
we
did.
I
did
a
presentation
to
the
diagnostics
group
about
18
months
ago
two
years
ago,
suggesting
so
that
the
minimum
that
you
would
require-
or
that's
required,
is
for
the
usdt
probes
to
be
enabled
in
the
linux
builds
okay,
so
mary
went
away
and
she
did
a
on
the
unofficial
repo
that
rod
was
managing.
B
She
did
actually
put
together
a
an
unofficial,
build
of
that,
but
we
never
got
that
into
core
or
into
the
into
the
core
release
or
the
official
builds
the
phrase
I'm
looking
for
apologies
right
and
the
challenge
is
that
it's
it's
it's
a
kind
of
a
cart.
It's
a
chicken
and
egg
situation.
Okay,
so,
and
the
reason
why
is
because
fundamentally
90
of
the
users
of
node.js?
B
Are
software
developers,
they're,
not
operations,
people
and
the
we
have
done
nothing
to
socialize
the
the
potential
ebf
ebpf
capabilities
to
the
operations
folks
within
within
any
sort
of
commercial
organization
or
any
of
the
vendors
as
well.
He
we
did
chat
with
some
of
the
folks
in
red
hat,
to
try
and
kick
something
off,
but
very,
very
slow
moving,
because
the
maturity
of
ebpf
it.
I
agree
with
you
completely.
It
is
where
we're
going
to
finish
up
in
terms
of
in
terms
of
monitoring
application
stacks
in
in
linux.
B
So
I
think
it
would
be
retrograde
to
remove
those
usdt's
right
now,
because
I
think
in
18
months
time
we'll
be
trying
to
put
them
back
in
and
that's
my
that's
my
opinion
on
it
and
always
has
been.
I
know
james
james
has
rightfully
so
does
not
want
unused
code
in
the
code
base,
but
I
think
they're
still
joint
and
the
sorry
not
giant
now,
but
the
smart
os
folks
have
agreed
that
they'll
start
putting
commits
in.
I
think
ben
raised
an
issue
about
getting
rid
of
or
downgrading
the
illumina
support.
B
A
Yeah
exactly
that,
that's
the
the
point
that
I
would
raise
actually
is.
I
think
that
a
good
step
would
be
even
knowing
that
it
will
be
a
long
discussion
in
the
core.
I
would
like
to
open
just
a
draft
pr
that
to
see
just
to
to
show
how
it
gonna
look
like
and
also
what
is
the
next
step
steps
for
that
and
after
I
have
a
draft
pier,
I
will
try
to
to
convince
the
the
team
that
it
is
very
helpful
for
anyone
and
like
building
tools
on
top
of
evpf.
A
For
instance,
I
believe
that
node
clinic
could
use
ebpf
as
a
flag
to
to
track
monitoring
stuffs,
and
I
think
that
it's,
it
shows
a
good
usage
but
yeah
it's.
I
think
the
problem
of
it
is,
as
you
mentioned,
a
name.
It's
percent
of
the
users
developers
and
most
of
them
doesn't
use
linux
and
yeah,
I
would
say
not
most
of
them,
but
yeah.
I
at
least
half
percent
doesn't
use
linux.
B
In
most
scenarios,
like
that's
yeah,
I
I
know,
because
I
I
spend
my
time
working
with
you
know
we're
working
with
customers
and
I
don't
spend
my
time
working
with
node.js
developers.
I
spend
my
time
working
with
ops.
People
who
are
putting
on
in
production
and
their
house
is
on
fire,
so
yeah,
yeah,
okay,.
A
Okay,
the
next
one
is
the
issue.
Five
three
two
re
reassess
the
tooling
list
and
the
maturity
status.
This
is
just
the
tracking
issue.
We
did
all
the
work.
I
guess
the
just
remaining
issue
is
the
ebpf
one
that
I
would
like
to
keep
open
for
a
while.
A
A
I'll
move
to
the
next
one
I
will
show
to
close.
I
actually
mentioned
to
closing
the
issue
and
see
if
someone
appears,
but
I
don't
see
that
we'll
have
any
objections.
A
The
next
one
is
the
user
track
document
tracking
documentation.
This
is
just
a
feedback.
We
have
this
issue
open
for
a
while.
The
idea
is
to
migrate
the
available
tutorials
to
the
node.js
or
the
memory
one
was
already
migrated.
A
So
this
is
a
good
good
good
step
and
I
believe
that
we
can
keep
keep
moving.
Just
one
thing
that
I
would
like
to
mention
is
that
the
profiling
we
have
actually
in
the
memory.
We
have
a
mention
to
valgrind,
but
I
did
a
test
recently
and
I'm
not
sure
if
this
is
working
as
expected,
at
least
not
in
the
official
build.
B
B
A
Amazing,
I
think
that's
it.
The
next
one
is
the
report.
Version
semantics
is
not
defined.
I
don't
know
about
this
issue
honestly.
Let
me
see.
A
Okay,
jewish
added
it
to
agenda
again.
A
A
That's
it.
I
will
watch
the
the
minutes
and
update
the
minutes,
but
sounds
good
a
lot
of
a
very
good
improvement
in
the
ll
note
part.
I
was
missing
that
and
that's
it
yeah.
B
Cool
okay,
so
this
we've
got
that
that
should
be
fairly
easy
to
do,
because
we've
got
tutorials
on
ibm
cloud
for
on
ibm's
documentation
about
using
ll
node
when
we
were
supporting
a
few
years
back.
So
it
should
be
just
a
lift
and
shift
for
that.
The
just
on
the
ebps
are
you.
B
B
Yeah
yeah,
I
I
know
I'm
not
expecting
it
I'd
like
to
say
I
had
the
conversation
two
years
ago,
so
I'm
not
expecting
anything
tomorrow,
but
I
just
it's
something
I
pushed
for
and
I'd
like
to
give
it
support
as
well,
which
is
why
I'm
ready
for
the
tracking
yeah.
But
I
know
it's
going
to
be
a
long
time.
A
Yeah,
so
as
soon
as
I
get
any
kind
of
feedback,
any
kind
of
insight,
I
contact
you
through
the
github
or
opengs,
is
like.