On 9/8/20 1:46 PM, Arturo Borrero Gonzalez wrote:
On 2020-09-04 23:14, Daniel Borkmann wrote:
root@x:~/x# clang -target bpf -Wall -O2 -c foo.c -o foo.o
In my honest opinion (debian hat), the simplification of the stack is a key
point for end users/developers. A gain in usability might justify a small
performance penalty.
Not really, both are independent from each other. Usability is typically achieved
through abstractions, e.g. hiding complexity in libraries (think of raw syscalls
vs libc). Same with the example of bpf or any other kernel subsystem fwiw, users
don't need to be aware of the details as applications abstract this away entirely
but they can benefit from efficiency underneath nevertheless. One example is how
systemd implements cgroup-aware firewalling and accounting for its services via bpf
[0]. Zero knowledge required while it presents meta data in user friendly way via
systemctl status. I'm not trying to convince you of bpf (or systemd), just that
this argument is moot.
I can think on both sysadmins and network apps developers, or even casual
advanced users. For many people, dealing with the network stack is already
challenging enough.
In the age of containers and distributed computing there is no such thing as
sysadmin anymore as we know it from our university days where a bunch of grey
bearded admins maintained a bunch of old sun boxes, printers, etc manually. ;-)
But yes, devops these days is complex, hence abstractions to improve usability
and gain introspection, but kernel is just a tiny fraction in the overall stack.
Also, ideally, servers would be clean of the GCC or CLANG suites.
Yes agree, one can compile out all other backends (in case of clang at least) that
would generate executable code though.
[0] http://0pointer.net/blog/ip-accounting-and-access-lists-with-systemd.html
