Re: [PATCH 4/4] bpf, docs: Explain helper functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 9, 2022 at 2:30 AM Dave Thaler <dthaler@xxxxxxxxxxxxx> wrote:
>
> > -----Original Message-----
> > From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>
> > Sent: Wednesday, November 9, 2022 1:51 AM
> > To: dthaler1968@xxxxxxxxxxxxxx
> > Cc: bpf <bpf@xxxxxxxxxxxxxxx>; Dave Thaler <dthaler@xxxxxxxxxxxxx>
> > Subject: Re: [PATCH 4/4] bpf, docs: Explain helper functions
> >
> > On Thu, Oct 27, 2022 at 7:46 AM <dthaler1968@xxxxxxxxxxxxxx> wrote:
> > >
> > > From: Dave Thaler <dthaler@xxxxxxxxxxxxx>
> > >
> > > Explain helper functions
> > >
> > > Signed-off-by: Dave Thaler <dthaler@xxxxxxxxxxxxx>
> > > ---
> > >  Documentation/bpf/instruction-set.rst | 18 +++++++++++++++++-
> > >  1 file changed, 17 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/bpf/instruction-set.rst
> > > b/Documentation/bpf/instruction-set.rst
> > > index aa1b37cb5..40c3293d6 100644
> > > --- a/Documentation/bpf/instruction-set.rst
> > > +++ b/Documentation/bpf/instruction-set.rst
> > > @@ -242,7 +242,7 @@ BPF_JSET  0x40   PC += off if dst & src
> > >  BPF_JNE   0x50   PC += off if dst != src
> > >  BPF_JSGT  0x60   PC += off if dst > src     signed
> > >  BPF_JSGE  0x70   PC += off if dst >= src    signed
> > > -BPF_CALL  0x80   function call
> > > +BPF_CALL  0x80   function call              see `Helper functions`_
> > >  BPF_EXIT  0x90   function / program return  BPF_JMP only
> > >  BPF_JLT   0xa0   PC += off if dst < src     unsigned
> > >  BPF_JLE   0xb0   PC += off if dst <= src    unsigned
> > > @@ -253,6 +253,22 @@ BPF_JSLE  0xd0   PC += off if dst <= src    signed
> > >  The eBPF program needs to store the return value into register R0
> > > before doing a  BPF_EXIT.
> > >
> > > +Helper functions
> > > +~~~~~~~~~~~~~~~~
> > > +Helper functions are a concept whereby BPF programs can call into a
> > > +set of function calls exposed by the eBPF runtime.  Each helper
> >
> > eBPF right next to BPF looks odd. Let's stick to BPF everywhere?
>
> Since the brand is eBPF, could we stick to eBPF everywhere except the
> actual defines (BPF_CALL, etc. have to be literal)?

I prefer to use BPF everywhere.



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux