| 1.1, Бэтман (?), 23:26, 09/09/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Все хорошо. Вот только писать eBPF программы вообще не тривиальное занятие. Может знатоки какой фреймворк подскажут?
| | |
| |
| |
| |
| 4.29, Аноним (29), 12:27, 10/09/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Нет это фреймворк похожий на питон который делает быстрый код.
| | |
|
|
| 2.11, null (??), 08:06, 10/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
Пиши на подмножестве C (без циклов) и получай на выходе байткод eBPF. Новость как раз об этом.
| | |
| |
| 3.41, Аноним (-), 16:47, 11/09/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Нет никаких подмножеств. Есть Чистый Си, и есть уже несовместимый с ним C++
| | |
|
| 2.19, Аноним (20), 10:04, 10/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
Вероятно, со временем добавят возможность писать на подмножестве C++
| | |
| |
| 3.32, X4asd (ok), 16:23, 10/09/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > Вероятно, со временем добавят возможность писать на подмножестве C++
зачем
| | |
|
| 2.26, Аноним (26), 11:02, 10/09/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Вот только писать eBPF программы вообще не тривиальное занятие.
в машинных кодах тоже непросто, для этого языки высокого уровня придумали
| | |
| |
| 3.30, Аноним (29), 12:29, 10/09/2019 [^] [^^] [^^^] [ответить]
| –3 +/– |
Как раз таки в машинных кодах достаточно просто, но муторно. Кстати в машинных кодах отлично получаются высоконагруженные парсеры.
| | |
|
|
| 1.2, Аноним (3), 23:50, 09/09/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Не верю что с разными версиями ядра такие приложения будут работать одинаково.
| | |
| |
| 2.9, anonymous (??), 00:20, 10/09/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Зависит от приложения, но многое покрывается тем, что для сборки требуются хедеры целевого ядра. Соответственно если скомпилится, то наверняка будет работать.
| | |
| 2.21, Аноним (20), 10:10, 10/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
Естесственно, это же достаточно низкоуровневая обработка пакетов и прочего. Для большего абстрагирования от версий ядра есть nftables.
| | |
|
| |
| 2.7, Аноним84701 (ok), 00:11, 10/09/2019 [^] [^^] [^^^] [ответить]
| +5 +/– |
 > Ура, наконец-то можно пихать проприетарщину в кернелмод!
Не только проприертарщину:
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, транслирующие высокоуровневый код из юзерспейса в машинный код для загрузки в ядро, такая вот штука.
| | |
|
| 1.6, Аноним (6), 00:10, 10/09/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Пробовал я клангом. К костыльному языку костыли приделали. Первая же variable-length структура сводит мозг их верификатору, но клангу до этого нет дела, он похоже вообще на знает про верификатор. С гцц наверняка будет похожая история.
| | |
| 1.10, Аноним (10), 07:34, 10/09/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
> Патчи для поддержи eBPF в GCC подготовлены инженерами из компании Oracle
jvm будут трансилровать в eBPF небось
| | |
| |
| 2.24, Аноним (20), 10:55, 10/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
Виртуальную машину JS напишут на eBPF. Вот тогда-то макаки заживут. Electron, Node.js - всё есть прямо в ядре. :)
| | |
| |
| 3.28, НяшМяш (ok), 11:33, 10/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Ох как будет гореть у гошников и явистов в юзерспейсе! /sarcasm
| | |
|
|
| |
| 2.25, Аноним (20), 11:01, 10/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
И чем там принципиально лучше? Вкорячили в прямо ядро интерпретатор исходного кода. А здесь сначала в байткод компиляют в юзерспейсе.
| | |
|
| 1.18, odin314 (ok), 09:49, 10/09/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 хочется надеться что с развитем eBPF зоопарк с сетевыми тулзами уменьшится
| | |
| |
| 2.31, пох. (?), 14:11, 10/09/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
наоборт же ж - каждая макака наклепает тебе сетевых тулзей на eBPF, патамушта модно - причем чтобы поменять что-нибудь - придется ковыряться в исходнике пакета и никак иначе.
И тулзы эти будут в каждой версии одного и того же дистрибутива - разные.
| | |
|
| 1.27, Аноним (26), 11:04, 10/09/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Какая мотивация писать новую виртуальную машину, когда есть куча готовых?
| | |
| 1.37, nc (ok), 08:45, 11/09/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 В чем смысл именно JIT (в его классическом понимании - трансляции команд "на лету", т.е. как минимум при каждом запуске, а то и в процессе исполнения программы)?
Как формат для распространения еще можно понять, но не проще ли сгенерировать код для целевого процессора один единственный раз при инсталляции софта на конкретную машину?
| | |
| |
| 2.39, Аноним84701 (ok), 13:14, 11/09/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> В чем смысл именно JIT (в его классическом понимании - трансляции команд
> "на лету", т.е. как минимум при каждом запуске, а то и
> в процессе исполнения программы)?
В классическом понимании -- для компиляции "на лету" ЯП с динамической типизацией/поздним связыванием (vtable, dynamic dispatch) и прочими кунтсштюкам.
ЕМНИП, придумали еще в 60 для лиспа.
При "классической" компиляции динамичного ЯП придется или генерировать код для всех возможных комбинаций вариантов типов/вызовов методов или же "разбирать" все во время выполнения (получим тот же интерпретатор, вид сбоку).
В случае JIT компиляции есть возможность отслеживать (tracing JIT) конкретно используемые типы и методы и компилировать только этот вариант.
| | |
| 2.40, Аноним (20), 15:17, 11/09/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>но не проще ли сгенерировать код для целевого процессора один единственный раз при инсталляции софта на конкретную машину?
А правила добавлять/вставлять/удалять на ходу?
| | |
|
|
