URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 118414
[ Назад ]
Исходное сообщение
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено opennews , 09-Сен-19 23:26 
В состав набора компиляторов GCC принят код для компиляции программ для встроенного в ядро Linux интерпретатора байткода eBPF.  Благодаря применению JIT-компиляции, в ядре байткод на лету транслируется в машинные инструкции и выполняется с производительностью нативного кода. Патчи с поддержкой eBPF приняты в ветку, на основе которой развивается выпуск GCC 10...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=51457

Содержание
Сообщения в этом обсуждении
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Бэтман , 09-Сен-19 23:26 
Все хорошо. Вот только писать eBPF программы вообще не тривиальное занятие. Может знатоки какой фреймворк подскажут?
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 09-Сен-19 23:52 
Cython он не про это но лучше юзай его)
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 10-Сен-19 10:05 
А Cython может в eBPF компилировать?
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 10-Сен-19 12:27 
Нет это фреймворк похожий на питон который делает быстрый код.
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено null , 10-Сен-19 08:06 
Пиши на подмножестве C (без циклов) и получай на выходе байткод eBPF. Новость как раз об этом.
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 11-Сен-19 16:47 
Нет никаких подмножеств. Есть Чистый Си, и есть уже несовместимый с ним C++
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 10-Сен-19 10:04 
Вероятно, со временем добавят возможность писать на подмножестве C++
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено X4asd , 10-Сен-19 16:23 
> Вероятно, со временем добавят возможность писать на подмножестве C++

зачем

  

"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено grsec , 10-Сен-19 17:23 
вот так
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено X4asd , 11-Сен-19 19:12 
> вот так

и всё же

"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено nobody , 11-Сен-19 12:00 
Было бы неплохо. В GPU шейдеры - уже
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 10-Сен-19 11:02 
> Вот только писать eBPF программы вообще не тривиальное занятие.

в машинных кодах тоже непросто, для этого языки высокого уровня придумали

"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 10-Сен-19 12:29 
Как раз таки в машинных кодах достаточно просто, но муторно. Кстати в машинных кодах отлично получаются высоконагруженные парсеры.
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 09-Сен-19 23:50 
Не верю что с разными версиями ядра такие приложения будут работать одинаково.
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено anonymous , 10-Сен-19 00:20 
Зависит от приложения, но многое покрывается тем, что для сборки требуются хедеры целевого ядра. Соответственно если скомпилится, то наверняка будет работать.
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 10-Сен-19 10:10 
Естесственно, это же достаточно низкоуровневая обработка пакетов и прочего. Для большего абстрагирования от версий ядра есть nftables.
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 09-Сен-19 23:56 
Ура, наконец-то можно пихать проприетарщину в кернелмод!
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним84701 , 10-Сен-19 00:11 
> Ура, наконец-то можно пихать проприетарщину в кернелмод!

Не только проприертарщину:
https://twitter.com/bleidl/status/943714277403357185
> Pour one out for this really nice Linux kernel bugdoor that P0 killed a few hours ago. Straight up unlimited R/W to all kernel memory via ebpf verifier bypass. One of the best/worst Linux kernel vulns of all time

https://lwn.net/Articles/742170/
:)

Сложные компоненты, да еще и с JIT, транслирующие высокоуровневый код из юзерспейса в машинный код для загрузки в ядро, такая вот штука.

"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 10-Сен-19 10:12 
Если сам себе враг, то пихай.
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 10-Сен-19 10:51 
Штеуд с МЕ, деадушку уже обул. Точнее сказать.
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 10-Сен-19 00:10 
Пробовал я клангом. К костыльному языку костыли приделали. Первая же variable-length структура сводит мозг их верификатору, но клангу до этого нет дела, он похоже вообще на знает про верификатор. С гцц наверняка будет похожая история.
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 10-Сен-19 07:34 
> Патчи для поддержи eBPF в GCC подготовлены инженерами из компании Oracle

jvm будут трансилровать в eBPF небось

"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 10-Сен-19 08:34 
и таких как ты тут 99%
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Andrey Mitrofanov_N0 , 10-Сен-19 08:49 
> и таких как ты тут 99%

В глубокой заморозке-то??

02.05.2017 21:09
   GCC 7.1 примечателен удалением из состава компилятора для языка Java,
https://www.opennet.me/opennews/art.shtml?num=46487

"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 10-Сен-19 10:55 
Виртуальную машину JS напишут на eBPF. Вот тогда-то макаки заживут. Electron, Node.js - всё есть прямо в ядре. :)
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено НяшМяш , 10-Сен-19 11:33 
Ох как будет гореть у гошников и явистов в юзерспейсе! /sarcasm
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено anonymous , 10-Сен-19 17:00 
WebAssembly на eBPF :)
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Joe B. , 10-Сен-19 08:28 
Когда на eBPF напишут эмулятор eBPF, то круг замкнётся.
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Andrey Mitrofanov_N0 , 10-Сен-19 08:31 
> Когда на eBPF напишут эмулятор eBPF, то круг замкнётся.

Компилятора Си, написанного на Си, хватит всем!  :-P

"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Анонас , 10-Сен-19 09:43 
Ничего эти линуксоиды сами придумать не могут http://www.opennet.me/opennews/art.shtml?num=38203
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 10-Сен-19 11:01 
И чем там принципиально лучше? Вкорячили в прямо ядро интерпретатор исходного кода. А здесь сначала в байткод компиляют в юзерспейсе.
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено bobr , 10-Сен-19 18:06 
Там JIT-компиляция.
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено odin314 , 10-Сен-19 09:49 
хочется надеться что с развитем eBPF зоопарк с сетевыми тулзами уменьшится
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено пох. , 10-Сен-19 14:11 
наоборт же ж - каждая макака наклепает тебе сетевых тулзей на eBPF, патамушта модно - причем чтобы поменять что-нибудь - придется ковыряться в исходнике пакета и никак иначе.
И тулзы эти будут в каждой версии одного и того же дистрибутива - разные.

"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 10-Сен-19 11:04 
Какая мотивация писать новую виртуальную машину, когда есть куча готовых?
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено nc , 11-Сен-19 08:45 
В чем смысл именно JIT (в его классическом понимании - трансляции команд "на лету", т.е. как минимум при каждом запуске, а то и в процессе исполнения программы)?
Как формат для распространения еще можно понять, но не проще ли сгенерировать код для целевого процессора один единственный раз при инсталляции софта на конкретную машину?
"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним84701 , 11-Сен-19 13:14 
> В чем смысл именно JIT (в его классическом понимании - трансляции команд
> "на лету", т.е. как минимум при каждом запуске, а то и
> в процессе исполнения программы)?

В классическом понимании -- для компиляции "на лету"  ЯП с динамической типизацией/поздним связыванием (vtable,  dynamic dispatch) и прочими кунтсштюкам.
ЕМНИП, придумали еще в 60 для лиспа.

При "классической" компиляции динамичного ЯП придется или генерировать код для всех возможных комбинаций вариантов типов/вызовов методов или же "разбирать" все во время выполнения  (получим тот же интерпретатор, вид сбоку).
В случае JIT компиляции есть возможность отслеживать (tracing JIT) конкретно используемые типы и методы и компилировать только этот вариант.

"В состав GCC принят бэкенд для компиляции в eBPF"
Отправлено Аноним , 11-Сен-19 15:17 
>но не проще ли сгенерировать код для целевого процессора один единственный раз при инсталляции софта на конкретную машину?

А правила добавлять/вставлять/удалять на ходу?