BPF List
 help / color / mirror / Atom feed
From: "Jose E. Marchesi" <jose.marchesi@oracle.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf <bpf@vger.kernel.org>
Subject: Re: EF_BPF_GNU_XBPF
Date: Wed, 02 Sep 2020 22:19:58 +0200	[thread overview]
Message-ID: <87y2ls0w41.fsf@oracle.com> (raw)
In-Reply-To: <CAADnVQ+AZvXTSitF+Fj5ohYiKWERN2yrPtOLR9udKcBTHSZzxA@mail.gmail.com> (Alexei Starovoitov's message of "Wed, 2 Sep 2020 12:31:53 -0700")


>> Hello BPF people!
>>
>> In order to ease the testing of the GCC bpf port we are adding a number
>> of extensions to the BPF ISA.
>>
>> We would like to use one bit in the e_flags field of the ELF header in
>> order to flag that the code in the ELF file is not plain eBPF:
>>
>> For EM_BPF:
>>
>> #define EF_BPF_GNU_XBPF 0x00000001
>>
>> Any objection?
>
> I've looked at your lpc slides and the extensions don't look like BPF
> extensions.
> At least I didn't see any attempt to make them verifiable.

It is an extension in the sense it is a superset of BPF.  Call it a
variant if you want.

As such, the property of being verifiable is irrelevant.  If we wanted
the extensions to be verifiable we would probably ask for them to be
added to BPF proper.  That's not the case, and that's precisely the
reason why we need to use that bit.

> In that sense it's not BPF and it's not correct to use EM_BPF for it.
> I suggest to define your own EM for your ISA.

Sorry, but that's not how ELF machine numbers work :)

It is perfectly normal, and also common practice, to use the same
machine code for several variants of the same base architecture, and I
see no reason for EM_BPF to be handled differently.  It would be silly,
and very inconvenient, to allocate a new machine number.

I don't think you people are using that bit in e_flags (or any bit, for
that matter).  So we just need to agree in reserving that bit for
EF_BPF_GNU_XBPF.

Shouldn't be a big matter surely?  There are 31 bits left ;)

  reply	other threads:[~2020-09-02 20:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02 18:18 EF_BPF_GNU_XBPF Jose E. Marchesi
2020-09-02 19:31 ` EF_BPF_GNU_XBPF Alexei Starovoitov
2020-09-02 20:19   ` Jose E. Marchesi [this message]
2020-09-02 20:32     ` EF_BPF_GNU_XBPF Alexei Starovoitov
2020-09-02 21:17       ` EF_BPF_GNU_XBPF Jose E. Marchesi
2020-09-02 21:33         ` EF_BPF_GNU_XBPF Daniel Borkmann
2020-09-02 22:10           ` EF_BPF_GNU_XBPF Jose E. Marchesi
2020-09-02 23:22             ` EF_BPF_GNU_XBPF David Miller
2020-09-02 23:40               ` EF_BPF_GNU_XBPF Jose E. Marchesi
2020-09-02 23:20           ` EF_BPF_GNU_XBPF David Miller
2020-09-02 23:18       ` EF_BPF_GNU_XBPF David Miller
2020-09-02 23:27         ` EF_BPF_GNU_XBPF Jose E. Marchesi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y2ls0w41.fsf@oracle.com \
    --to=jose.marchesi@oracle.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox