Компания Oracle сообщила (https://blogs.oracle.com/linux/dtrace-on-fedora) о работе по передаче связанных с DTrace изменений в upstream и планах по реализации технологии динамической отладки DTrace поверх штатной инфрастуруктуры ядра Linux, а именно с использованием таких подсистем, как eBPF. Изначально основной проблемой с использованием DTrace в Linux была несовместимость на уровне лицензий, но в 2018 году компания Oracle перелицензировала (https://www.opennet.me/opennews/art.shtml?num=48078) код DTrace под GPLv2.
DTrace уже длительное время (https://www.opennet.me/opennews/art.shtml?num=35586) предлагается в составе расширенного ядра для дистрибутива Oracle Linux, но для своего использования в других дистрибитувах требует применения дополнительных патчей для ядра, что ограничивает использование указанной технологии. В качестве примера, компания Oracle подготовила (https://blogs.oracle.com/linux/dtrace-on-fedora) детальную инструкцию по установке и использованию DTrace в Fedora Linux. Для установки требуется сборка инструментария (https://github.com/oracle/dtrace-utils) и применение ядра Linux, пересобранного с патчами (https://github.com/oracle/dtrace-linux-kernel.git). Для автоматизации выполнения сборки ядра с патчами Oracle и Fedora предложен скрипт (https://github.com/oracle/dtrace-linux-kernel/blob/5.2.7/sam...).
eBPF представляет собой встроенный в ядро Linux интерпретатор байткода, позволяющий создавать обработчики сетевых операций, отслеживать работу систем, перехватывать системные вызовы, контролировать доступ, обрабатывать события с сохранением хронометража (perf_event_open), подсчитывать частоту и время выполнения операций, выполнять трассировку с использованием kprobes/uprobes/tracepoints. Благодаря применению JIT-компиляции, байткод на лету транслируется в машинные инструкции и выполняется с производительностью нативного кода. DTrace может быть реализован поверх eBPF, по аналогии с тем, как поверх eBPF работают (https://www.opennet.me/opennews/art.shtml?num=45391) существующие инструменты трассировки.
Изначально технология DTrace была разработана для операционной системы Solaris для решения задач по динамической трассировке ядра системы и конечных приложений, давая пользователю возможность детально отслеживать поведение системы и в режиме реального времени производить диагностику проблем. В процессе отладки DTrace не влияет на работу исследуемых приложений и никак не отражается на их производительности, что позволяет организовать анализ работающих систем на лету. Из сильных сторон DTrace отмечается высокоуровневый язык D, похожий на AWK, на котором значительно проще создавать сценарии трассировки, чем при применении предлагаемых для eBPF средств написания обработчиков на языках C, Python и Lua с внешними библиотеками.
URL: https://blogs.oracle.com/linux/dtrace-on-fedora
Новость: https://www.opennet.me/opennews/art.shtml?num=51287
Я, конечно, совершенно не в теме, но как нечто похожее на AWK может быть удобнее нормальных языков?
Набросик так себе.
Люди, могущие в AWK, повидали достаточно, чтобы отреагировать на подобные заявления снисходительно улыбкой.
Ну я могу в awk, когда прижмёт. Но не представляю задачи, котору на нём было бы удобнее решать, чем на perl.
Perl довольно многое взял из awk. Творчески переработав опыт поколений.
это типа перл не похож на awk?
Это типа perl намного удобнее awk на практически всех задачах, для которых в принципе может сгодиться awk.
>Но не представляю задачи, котору на нём было бы удобнее решать, чем на perl.Обработка таблиц без сложной логики - получается лаконичнее, чем на perl
Да это даже не набросик. Ну, то есть можно и в машинных кодах писать, но оно ж чудовищно. Чем это может быть лучше, чем нормальная структурированная запись? Когда оно создавалось - это было логично, тогда каждый байт экономили. А сейчас, уж простите, я лучше явно напишу while(line = read(file){...} чем буду использовать заклинания из AWK. Так его хоть прочесть и поправить можно без расшифровки.
Что в awk расшифровывать, он же прост как топор.
Вопрос привычки. Через несколько сотен раз набирания "while(line = read(file)" захочется добавить макро, делающее "while (defined($_ = <file_E>))" из "while(<file_E>)", например. Ну так уже добавлено.Кому-то надоедает писать foreach i in L { sum += i }, и он начинает использовать foldr (+) L, а потом, может быть и +/L, ну а кому-то наверное и нет.
> нечто похожее на AWKЭто ты про что?
Это он про D-as-in-DTrace-не-путать-с-D-который-(C++)++
//offtop
eBPF - быстро, а jvm - медленно?
> //offtop
> Oracle - быстро, а Oracle - медленно???
Реализовать подсистему динамической трассировки ядра на JVM - это было бы ново, оригинально.
> //offtop
> eBPF - быстро, а jvm - медленно?Стековая виртуальная машина с поддержкой объектов-методов и еще целой кучи жирностей != регистровая VM для, по сути, обрезанного DSL.
https://blogs.igalia.com/dpino/2019/01/07/introduction-to-xd.../
А чо Ораколь ещё не додумался жабу в ведро запустить? Всего-то модуль наклепать!
Хорошая штука eBPF.> Ashish Bijlani of Georgia Tech presented at this week's Linux Foundation Open-Source Summit on the work they are pursuing for making user-space file-systems faster. The short explanation of what they are doing with this project called "ExtFUSE" is to provide an extension framework of a "thin" layer of handlers within the kernel that leverage the eBPF in-kernel virtual machine for speeding up some I/O operations.
> By using these "thin" kernel extensions they are able to avoid some user-space context switching and handling some metadata caching within the kernel while still sticking to the concept of the file-system implementation in user-space.
> Хорошая штука eBPF.
>>"thin" kernel extensions they are able to avoid some user-space context switching and handling some metadata caching within the kernel while still stickingПочти как MS-DOS .
Мне одному кажется концепция монолитного ядра и необходимость тащить всё в него - устаревшей и тупиковой?
> Мне одному кажется концепция монолитного ядра и необходимость тащить всё в него
> - устаревшей и тупиковой?Не мешайте Землину-Торвальдсу таки делать свой гешефт !
Вынести из ядра подсистему динамической трассировки ядра - это было бы ново, оригинально.
Вам и Таненбауму
Вы внимательно читаете новость?
Всё уже идет к тому, что в ядре будет только jit компилятор, а все остальное будет загружаться динамически. :)
Лучше всего если JIT будет прямо в CPU. Но так как JIT для всех языков туда не засунешь, будет для WebAsm.