What FreeBSD think of eBPF?

F

Ferocious1881

Without taking relevance in why FreeBSD had not implemented eBPF, unless hating eBPF is doing so.

Linux created something which named eBPF in a sacrilegious act from our BPF(4). It does reduce a crazyness of bad engineering called Linuxism, or it is just a good idea?

Are his promises of being able to do better performance analysis something nonsensical, or it is just vaporware?
Is not like it magically allows to trace back every call to the call instruction or all of the cpu calls without any kind of performance penalty.

In the first case what is the response from FreeBSD?
 
I would have to compare it to Dtrace to form an opinion. Even if eBPF is better in some ways that would still leave the question open whether to approach the missing functionality by putting eBPF in the kernel or by adding the required features to Dtrace.

I have no reason to hate eBPF but keep in mind that GPLed code cannot just be taken from Linux and added to FreeBSD.
 
cracauer@ said:
I would have to compare it to Dtrace to form an opinion. Even if eBPF is better in some ways that would still leave the question open whether to approach the missing functionality by putting eBPF in the kernel or by adding the required features to Dtrace.

I have no reason to hate eBPF but keep in mind that GPLed code cannot just be taken from Linux and added to FreeBSD.
Click to expand...
Never said that one have to add GPL code, but it kind of is an standard https://www.ietf.org/archive/id/draft-thaler-bpf-isa-00.html.
Except for their stupid functions.

I better not peak Linux or any kind of copyleft code, I would not like be contaminated.

Also in that case just add missing functionality to DTrace, but still are open questions about the other uses of eBPF.
 
eBPF is a substantially different technology, eBPF runs in a LLVM assisted byte-code within some VM-like environment. One of the great advantages is that BPF is more general more public oriented and allows running of some more complex code given that it complies to what verifier thinks is OK. Quite a different approach. I'm no DTrace internals expert, merely a consumer, but DTrace runs the D code in a much more straightforward/different way. Nowadays, BPF can run even limited loops where the verifier can be sure they're bound enough.
 
I have to admit had no idea my machine was running bpf or shall I call it cBPF....

Sorry to disrupt the thread.
 
Andriy said:
From just reading the code?
I am afraid that you have been misinformed.
Click to expand...
By the way the IBM PC's BIOS was reversed engineered, if you have never read code you are safe, but if you have read the code and produce something similar you may no be safe. And it way I understood. Anyway better safe than sorry.
 
Ferocious1881 said:
By the way the IBM PC's BIOS was reversed engineered, if you have never read code you are safe, but if you have read the code and produce something similar you may no be safe. And it way I understood. Anyway better safe than sorry.
Click to expand...
That BIOS wasn't under GPL, though :-)
Even better to be well informed.
 
You must log in or register to reply here.
Back
Top