All of lore.kernel.org
 help / color / mirror / Atom feed
* LSF/MM/BPF activity proposal: Compiled BPF
@ 2023-01-30 17:47 Jose E. Marchesi
  2023-01-31 19:52 ` [Lsf-pc] " Daniel Borkmann
  0 siblings, 1 reply; 4+ messages in thread
From: Jose E. Marchesi @ 2023-01-30 17:47 UTC (permalink / raw)
  To: lsf-pc
  Cc: bpf, david.faust, elena.zannoni, Alexei Starovoitov,
	James Hilliard, Yonghong Song, ndesaulniers


Hello.

We would like to suggest to the LSF/MM/BPF organization to have a
working session on "compiled BPF", i.e. on the part of BPF that involves
compilers and linkers.  This mainly involves the two mainstream
compilers that target BPF: clang and GCC, but other BPF toolchains are
slowly appearing (like the Rust compiler) and that makes it even more
important to consolidate compiled BPF.

Examples of topics to cover are the covergence of the support in both
clang/llvm and GCC, several aspects of the ABI that need to be
discussed/clarified/decided in order to avoid undefined compiler
behavior and divergences, issues related to the BPF standarization, and
suggestions on how to lift some of the existing limitations impacting
BPF C programs.

The goal is to reach agreements about particular things, document the
agreements, stick to them, and a clear plan to implement whatever is
needed in the respective compilers/tools.

Potential participants in case the activity takes place:

- Both David Faust (GNU toolchain, BPF port hacker) and myself (GNU
  toolchain, BPF port maintainer) are willing to attend the event,
  prepare discussion material, organize and participate in the
  discussions.

- Nick Desaulniers (LLVM maintainer) is also interested in attending and
  participating, provided other compromises he has in May don't get in
  the way.

- More? (Please add yourself to this list by replying to this email in
  case you are interested.)

Would the BPF community and the LSF/MM/BPF organization be interested in
having such an activity?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Lsf-pc] LSF/MM/BPF activity proposal: Compiled BPF
  2023-01-30 17:47 LSF/MM/BPF activity proposal: Compiled BPF Jose E. Marchesi
@ 2023-01-31 19:52 ` Daniel Borkmann
  2023-01-31 23:09   ` Jose E. Marchesi
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Borkmann @ 2023-01-31 19:52 UTC (permalink / raw)
  To: Jose E. Marchesi, lsf-pc
  Cc: ndesaulniers, david.faust, elena.zannoni, James Hilliard,
	Yonghong Song, bpf, Alexei Starovoitov

On 1/30/23 6:47 PM, Jose E. Marchesi wrote:
> 
> Hello.
> 
> We would like to suggest to the LSF/MM/BPF organization to have a
> working session on "compiled BPF", i.e. on the part of BPF that involves
> compilers and linkers.  This mainly involves the two mainstream
> compilers that target BPF: clang and GCC, but other BPF toolchains are
> slowly appearing (like the Rust compiler) and that makes it even more
> important to consolidate compiled BPF.
> 
> Examples of topics to cover are the covergence of the support in both
> clang/llvm and GCC, several aspects of the ABI that need to be
> discussed/clarified/decided in order to avoid undefined compiler
> behavior and divergences, issues related to the BPF standarization, and
> suggestions on how to lift some of the existing limitations impacting
> BPF C programs.
> 
> The goal is to reach agreements about particular things, document the
> agreements, stick to them, and a clear plan to implement whatever is
> needed in the respective compilers/tools.
> 
> Potential participants in case the activity takes place:
> 
> - Both David Faust (GNU toolchain, BPF port hacker) and myself (GNU
>    toolchain, BPF port maintainer) are willing to attend the event,
>    prepare discussion material, organize and participate in the
>    discussions.
> 
> - Nick Desaulniers (LLVM maintainer) is also interested in attending and
>    participating, provided other compromises he has in May don't get in
>    the way.

Plus Yonghong Song with regards to LLVM BPF backend.

> - More? (Please add yourself to this list by replying to this email in
>    case you are interested.)
> 
> Would the BPF community and the LSF/MM/BPF organization be interested in
> having such an activity?

Yes, we can definitely add this to the agenda for the BPF track. This sounds
very reasonable to me!

Thanks Jose!

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Lsf-pc] LSF/MM/BPF activity proposal: Compiled BPF
  2023-01-31 19:52 ` [Lsf-pc] " Daniel Borkmann
@ 2023-01-31 23:09   ` Jose E. Marchesi
  2023-02-01  7:54     ` Yonghong Song
  0 siblings, 1 reply; 4+ messages in thread
From: Jose E. Marchesi @ 2023-01-31 23:09 UTC (permalink / raw)
  To: Daniel Borkmann
  Cc: lsf-pc, ndesaulniers, david.faust, elena.zannoni, James Hilliard,
	Yonghong Song, bpf, Alexei Starovoitov


> On 1/30/23 6:47 PM, Jose E. Marchesi wrote:
>> Hello.
>> We would like to suggest to the LSF/MM/BPF organization to have a
>> working session on "compiled BPF", i.e. on the part of BPF that involves
>> compilers and linkers.  This mainly involves the two mainstream
>> compilers that target BPF: clang and GCC, but other BPF toolchains are
>> slowly appearing (like the Rust compiler) and that makes it even more
>> important to consolidate compiled BPF.
>> Examples of topics to cover are the covergence of the support in
>> both
>> clang/llvm and GCC, several aspects of the ABI that need to be
>> discussed/clarified/decided in order to avoid undefined compiler
>> behavior and divergences, issues related to the BPF standarization, and
>> suggestions on how to lift some of the existing limitations impacting
>> BPF C programs.
>> The goal is to reach agreements about particular things, document
>> the
>> agreements, stick to them, and a clear plan to implement whatever is
>> needed in the respective compilers/tools.
>> Potential participants in case the activity takes place:
>> - Both David Faust (GNU toolchain, BPF port hacker) and myself (GNU
>>    toolchain, BPF port maintainer) are willing to attend the event,
>>    prepare discussion material, organize and participate in the
>>    discussions.
>> - Nick Desaulniers (LLVM maintainer) is also interested in attending
>> and
>>    participating, provided other compromises he has in May don't get in
>>    the way.
>
> Plus Yonghong Song with regards to LLVM BPF backend.

Indeed, it would make very little sense for the whole thing to happen
without him.  I just didn't want to speak for him (I consulted with both
David and Nick before sending the proposal) ;)

>
>> - More? (Please add yourself to this list by replying to this email in
>>    case you are interested.)
>> Would the BPF community and the LSF/MM/BPF organization be
>> interested in
>> having such an activity?
>
> Yes, we can definitely add this to the agenda for the BPF track. This sounds
> very reasonable to me!
>
> Thanks Jose!

Awesome :)
Thanks to you!

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Lsf-pc] LSF/MM/BPF activity proposal: Compiled BPF
  2023-01-31 23:09   ` Jose E. Marchesi
@ 2023-02-01  7:54     ` Yonghong Song
  0 siblings, 0 replies; 4+ messages in thread
From: Yonghong Song @ 2023-02-01  7:54 UTC (permalink / raw)
  To: Jose E. Marchesi, Daniel Borkmann
  Cc: lsf-pc, ndesaulniers, david.faust, elena.zannoni, James Hilliard,
	Yonghong Song, bpf, Alexei Starovoitov



On 1/31/23 3:09 PM, Jose E. Marchesi wrote:
> 
>> On 1/30/23 6:47 PM, Jose E. Marchesi wrote:
>>> Hello.
>>> We would like to suggest to the LSF/MM/BPF organization to have a
>>> working session on "compiled BPF", i.e. on the part of BPF that involves
>>> compilers and linkers.  This mainly involves the two mainstream
>>> compilers that target BPF: clang and GCC, but other BPF toolchains are
>>> slowly appearing (like the Rust compiler) and that makes it even more
>>> important to consolidate compiled BPF.
>>> Examples of topics to cover are the covergence of the support in
>>> both
>>> clang/llvm and GCC, several aspects of the ABI that need to be
>>> discussed/clarified/decided in order to avoid undefined compiler
>>> behavior and divergences, issues related to the BPF standarization, and
>>> suggestions on how to lift some of the existing limitations impacting
>>> BPF C programs.
>>> The goal is to reach agreements about particular things, document
>>> the
>>> agreements, stick to them, and a clear plan to implement whatever is
>>> needed in the respective compilers/tools.
>>> Potential participants in case the activity takes place:
>>> - Both David Faust (GNU toolchain, BPF port hacker) and myself (GNU
>>>     toolchain, BPF port maintainer) are willing to attend the event,
>>>     prepare discussion material, organize and participate in the
>>>     discussions.
>>> - Nick Desaulniers (LLVM maintainer) is also interested in attending
>>> and
>>>     participating, provided other compromises he has in May don't get in
>>>     the way.
>>
>> Plus Yonghong Song with regards to LLVM BPF backend.
> 
> Indeed, it would make very little sense for the whole thing to happen
> without him.  I just didn't want to speak for him (I consulted with both
> David and Nick before sending the proposal) ;)

Sounds good to me. We can continue to discuss all possible divergences
in the mailing list and discuss/resolve the remaining in LSF/MM/BPF
conference.

> 
>>
>>> - More? (Please add yourself to this list by replying to this email in
>>>     case you are interested.)
>>> Would the BPF community and the LSF/MM/BPF organization be
>>> interested in
>>> having such an activity?
>>
>> Yes, we can definitely add this to the agenda for the BPF track. This sounds
>> very reasonable to me!
>>
>> Thanks Jose!
> 
> Awesome :)
> Thanks to you!

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-02-01  7:55 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-30 17:47 LSF/MM/BPF activity proposal: Compiled BPF Jose E. Marchesi
2023-01-31 19:52 ` [Lsf-pc] " Daniel Borkmann
2023-01-31 23:09   ` Jose E. Marchesi
2023-02-01  7:54     ` Yonghong Song

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.