The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Представлена библиотека Aya для создания eBPF-обработчиков на языке Rust

16.06.2021 10:30

Представлен первый выпуск библиотеки Aya, позволяющей создавать на языке Rust обработчики eBPF, запускаемые внутри ядра Linux в специальной виртуальной машине с JIT. В отличие от других инструментов для разработки eBPF-программ, Aya не использует libbpf и компилятор bcc, а предлагает собственную реализацию, написанную на Rust, которая использует crate-пакет libc для прямого обращения к системным вызовам ядра. Для сборки Aya не требуется наличие инструментария для языка C и заголовочных файлов ядра. Код библиотеки распространяется под лицензиями MIT и Apache 2.0.

Основные возможности:

  • Поддержка формата BTF (BPF Type Format), предоставляющего информацию о типах в псевдокоде BPF для проверки типов и сопоставления с типами, предоставляемыми текущим ядром. Применение BTF даёт возможность создавать универсальные eBPF-обработчики, которые можно использовать без перекомпиляции с разными версиями ядра Linux.
  • Поддержка вызовов "bpf-to-bpf", глобальных переменных и инициализаторов, что позволяет оформлять программы для eBPF по аналогии с обычными программами, использующими aya в качестве runtime, переопределяющем функции с учётом работы в eBPF.
  • Поддержка внутренних типов ядра, включая обычные массивы, хэши (hash map), стеки, очереди, трассировки стека, а также структуры для сокетов и отслеживания производительности.
  • Возможность создавать различные типы eBTF-программ, включая программы для фильтрации и управления трафиком, обработчики cgroup и различных операций с сокетами, XDP-программы.
  • Поддержка платформ для асинхронной обработки запросов в неблокирующем режиме tokio и async-std.
  • Быстрая сборка, без привязки к сборке ядра и заголовочным файлам ядра.

Проект пока рассматривается как экспериментальный - API ещё не стабилизирован и продолжает развиваться. Также ещё не реализованы все задуманные возможности. До конца года разработчики рассчитывают довести функциональность Aya до паритета с libbpf, а в январе 2022 года сформировать первый стабильный релиз. Также планируется объединить части Aya, необходимые для написания кода на Rust для ядра Linux с компонентами, работающими в пространстве пользователя и используемыми для загрузки, прикрепления и взаимодействия с программами eBPF.

Напомним, что eBPF представляет собой встроенный в ядро Linux интерпретатор байткода, позволяющий создавать обработчики сетевых операций, отслеживать работу систем, перехватывать системные вызовы, контролировать доступ, обрабатывать события с сохранением хронометража, подсчитывать частоту и время выполнения операций, выполнять трассировку с использованием kprobes/uprobes/tracepoints. Благодаря применению JIT-компиляции, байткод на лету транслируется в машинные инструкции и выполняется с производительностью нативного кода. XDP предоставляет средства для запуска BPF-программ на уровне сетевого драйвера, с возможностью прямого доступа к DMA-буферу пакетов, что позволяет создавать высокопроизводительные обработчики для работы в условиях большой сетевой нагрузки.

  1. Главная ссылка к новости (https://confused.ai/posts/anno...)
  2. OpenNews: Уязвимости в подсистеме eBPF, позволяющие выполнить код на уровне ядра Linux
  3. OpenNews: Microsoft подготовил реализацию eBPF для Windows
  4. OpenNews: Компания Oracle намерена переработать DTrace для Linux с использованием eBPF
  5. OpenNews: В ветку ядра Linux-next добавлен код для разработки драйверов на языке Rust
  6. OpenNews: Поддержка Rust для ядра Linux столкнулась с критикой Торвальдса
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/55340-bpf
Ключевые слова: bpf, rust, kernel
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (121) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, lockywolf (ok), 10:39, 16/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    И как у этого crate с thread safety?
     
     
  • 2.7, Ordu (ok), 11:24, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как обычно, надо полагать. Data race исключаются как класс, пока ты не прибегаешь к unsafe, а остальное всё в твоих руках. А почему ты спрашиваешь? Есть основания полагать, что у него ситуация с thread-safety отличается от дефолтной в расте?
     
     
  • 3.14, lockywolf (ok), 12:14, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Как обычно, надо полагать. Data race исключаются как класс, пока ты не
    > прибегаешь к unsafe, а остальное всё в твоих руках. А почему
    > ты спрашиваешь? Есть основания полагать, что у него ситуация с thread-safety
    > отличается от дефолтной в расте?

    Ну, я помню смешные курьёзы с errno, который в стандарте переменная, но для thread-safety сделано как макрос, разворачивающийся в вызов функции. Интересно, помнили ли об этом растовики, когда писали свой crate.

     
     
  • 4.15, Ordu (ok), 12:38, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну, я помню смешные курьёзы с errno, который в стандарте переменная, но
    > для thread-safety сделано как макрос, разворачивающийся в вызов функции.

    Чё за курьёзы? Я не помню. Мне было бы интересно посмотреть, как кто-то не справился не заметить таких нюансов.

    > Интересно, помнили
    > ли об этом растовики, когда писали свой crate.

    А, ну это общая проблема создания safe API поверх unsafe операций. Тут она несколько осложняется тем, что там unsafe будет во все поля из-за интерфейса с внешним кодом, который rustc не может проанализировать на safety, и поэтому на всякий случай считает unsafe. То есть, в unsafe будет заворачиваться слишком много, и поэтому придётся проявлять чудеса умения обходить грабли.

    Да, вероятность косяков повышена. Тут ты прав.

     
  • 4.19, Аноним (19), 13:29, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    '''
    __thread int errno;                                                            
    extern __thread int __libc_errno __attribute__ ((alias ("errno"))) attribute_hidden;
    '''
     
  • 3.38, Прорыв_запарты_фелиал (ok), 20:59, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • –4 +/
    А вот и жертвы пропаганды нарисовались. Модель памяти раста не предполагает конкурентного доступа, а когда нет конкурентного доступа нет гонок. Тебя обманули. Меньше лозунгов ретранслируй и больше тему изучай.

    Представляешь, отличается. Раз раст не может в конкурентный доступ, то любое его наличие требует unsafe, хотя unsafe к расту не имеет никакого отношения, потому как имеет как минимум другую модель памяти, даже базовые примитивы иные. Потому как это просто обёртка поверх llvm-ir и сишного интеропа с llvm.

     
     
  • 4.41, Ordu (ok), 21:20, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > А вот и жертвы пропаганды нарисовались. Модель памяти раста не предполагает конкурентного
    > доступа, а когда нет конкурентного доступа нет гонок.

    race condition в расте делается элементарно. Сделай два mutex'а, и попробуй залочить их оба последовательно из параллельных потоков.

    data race в расте элементарно не делается, unsafe нужен, как раз в силу этой самой модели памяти.

    А конкурентный доступ есть, чтобы какую бы лапшу _тебе_ пропаганда не вешала на уши, есть Arc для менеджмента памятью в конкурентном окружении, и есть Mutex, для конкрентного доступа. Есть Send, говорящий о том, что значения данного типа можно прокидывать между потоками выполнения. Наконец, есть Sync, для типов навроде Mutex'а, которые не просто можно прокидывать между потоками, но шарить между потоками, в смысле иметь указатели на них в разных потоках одновременно.

    И если Arc и Mutex -- это творения стандартной библиотеки и дают простор порассуждать, что это не раст как таковой, а библиотека к нему, то Send и Sync -- это трейты-маркеры типов, прошитые в язык, наряду с другими трейтами-маркерами формирующими модель памяти раста (чтобы это не означало), такими как Clone, Copy, ?Sized.

    > Тебя обманули.

    Конечно.

    > Представляешь, отличается. Раз раст не может в конкурентный доступ, то любое его
    > наличие требует unsafe,

    Да, ты прикинь, они врут всё про безопасность: массивы тоже в расте не реализуются без unsafe'ов. Ты реально можешь заглянуть в сорцы core::slice и увидеть там как unsafe на unsafe unsafe'ом погоняет: https://doc.rust-lang.org/src/core/slice/mod.rs.html#86

     
     
  • 5.46, Прорыв_запарты_фелиал (ok), 21:36, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Раст не умеет в mutex - он не реализуется на расте Это раз Два - мутекс это не... большой текст свёрнут, показать
     
     
  • 6.60, zig (??), 22:23, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Братишка, напиши про zig, а то чет его тут пеарят.
     
     
  • 7.64, Аноним (64), 02:12, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я пиарил. Хотел на нём базу данных написать. Я руками его не трогал, но документацию и статьи внимательно прочитал.

    Стоит посмотреть GitHub Issues - сразу становится понятно что он не готов для чего-то серьёзного.

    Буду писать на Rust.

     
  • 6.63, Ordu (ok), 22:33, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Да-да, точно, и массивов в расте нет, потому что они реализуются на расте Что з... большой текст свёрнут, показать
     
     
  • 7.80, Прорыв_запарты_фелиал (ok), 12:57, 17/06/2021 Скрыто модератором
  • +1 +/
     
  • 2.134, Аноним (134), 15:30, 18/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > ... safety?

    Там где есть JIT безопасности нет!

     

  • 1.2, mos87 (ok), 10:47, 16/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    прикольно бы еще напомнить что такое (e)bpf
     
     
  • 2.20, Аноним (-), 13:40, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > прикольно бы еще напомнить что такое (e)bpf

    Extended BlackArch Packet Filter
    Хотя некоторые утверждают, что придумано оно было еще в доситорические времена в Blue Linux.

     
     
  • 3.35, Аноним (35), 19:34, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> прикольно бы еще напомнить что такое (e)bpf
    > Extended BlackArch Packet Filter

    не BlackArch, а Berkley

     
     
  • 4.36, yourc (?), 19:37, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    По-моему, там ирония. Но это не точно.
     
  • 4.58, Аноним. (?), 22:14, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >>> прикольно бы еще напомнить что такое (e)bpf
    >> Extended BlackArch Packet Filter
    > не BlackArch, а Berkley

    Berkeley Linux? Никогда о таком не слышал.

     
     
  • 5.85, Аноним (85), 14:06, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это предыдущая версия до redhat enterprise bsd
     
     
  • 6.93, Аноним (-), 14:57, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Это предыдущая версия до redhat enterprise bsd

    БЗДы по определению могут только воровать из линуха! Даже JIT для BPF - и тот оперативно утянули!
    https://github.com/freebsd/freebsd-src/blob/master/sys/amd64/conf/NOTES
    > # BPF_JITTER adds support for BPF just-in-time compiler.
    >  options BPF_JITTER
    >

     
  • 2.71, КО (?), 08:56, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Очередной костыль, если вам так будет понятнее
     

  • 1.3, Qwerty (??), 10:52, 16/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –12 +/
    Что бы там луддиты не говорили, а всё-таки за Хрустом будущее.
     
     
  • 2.4, Аноним (4), 11:08, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Ага за джаваскриптом, луддит.
     
  • 2.11, Аноним (11), 12:02, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Спасибо, поржал. Продолжайте снабжать нас веселыми историями.
     
     
  • 3.17, JackoNeill (?), 13:02, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Самое страшное то, что весьма вероятно, смеяться то он будет как раз последним.
     
     
  • 4.24, Самый Лучший Гусь (?), 16:57, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Девушки рыдают, матросы смеются, как говорится.
     
  • 4.74, Урри (ok), 11:17, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    "А Таня была в каске и только засмеялась" (с)
     

  • 1.5, Аноним (4), 11:09, 16/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Все равно потечет и будет небезопасной зачем тут раст то?
     
  • 1.6, Аноним (6), 11:21, 16/06/2021 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • +13 +/
     
     
  • 2.9, Аноним (9), 11:28, 16/06/2021 Скрыто модератором
  • +1 +/
     
     
  • 3.12, Lex (??), 12:04, 16/06/2021 Скрыто модератором
  • –2 +/
     
  • 3.13, заминированный тапок (ok), 12:10, 16/06/2021 Скрыто модератором
  • +1 +/
     
  • 3.16, Аноним (11), 12:56, 16/06/2021 Скрыто модератором
  • +/
     
  • 2.10, Корец (?), 11:29, 16/06/2021 Скрыто модератором
  • +2 +/
     

     ....ответы скрыты модератором (5)

  • 1.8, псевдонимус (?), 11:24, 16/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    >апи ещё не стабилизирован

    Для раста это нормально.

     
     
  • 2.37, Онаним (?), 19:50, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Да и "пока" там можно смело убирать.
     

  • 1.27, anonymous (??), 17:39, 16/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Мляяя... jit в ядре, из под обычного пользователя, версия 2 - powered by rust. Дедушка Столлман, срочно, пили гпл4, проприерасты прорвались.
     
     
  • 2.129, burjui (ok), 13:12, 18/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Причём тут проприетарщина и GPL? У тебя каша в голове.
     

  • 1.28, Аноним (28), 17:54, 16/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Кто бы сомневался что всё равно без libc ничего не могут. Хипстеры такие хипстеры.
     
     
  • 2.30, n00by (ok), 18:13, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Хотел было спросить, зачем там

    pub unsafe extern "C" fn malloc(size: size_t) -> *mut c_void

    но нашёл вот это:

    pub unsafe extern "C" fn strlen(cs: *const c_char) -> size_t

    https://docs.rs/libc/0.2.97/libc/fn.strlen.html

     
     
  • 3.42, Аноним (-), 21:22, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > но нашёл вот это:
    > pub unsafe extern "C" fn strlen(cs: *const c_char) -> size_t
    > https://docs.rs/libc/0.2.97/libc/fn.strlen.html

    И чо? Тебя поразило в самое сердце, что для взаимодействия с внешними либами можно не переизобретать велосипед, а использовать решения для тех самых внешних либ? (для латентных ЖСкриптозников поясню - в Ржавчине char - это 4 байта, а String - отдельный тип в кодировке UTF-8, а не массив с костыл^W набором чаров)

     
     
  • 4.65, n00by (ok), 06:52, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> но нашёл вот это:
    >> pub unsafe extern "C" fn strlen(cs: *const c_char) -> size_t
    >> https://docs.rs/libc/0.2.97/libc/fn.strlen.html
    > И чо? Тебя поразило в самое сердце, что для взаимодействия с внешними
    > либами можно не переизобретать велосипед, а использовать решения для тех самых
    > внешних либ?

    Да, меня это поразило. Вы еще про Бойер-Мура напишите для строк в 2 гигабайта, что бы я спросил: а зачем?

    > (для латентных ЖСкриптозников поясню - в Ржавчине char -
    > это 4 байта, а String - отдельный тип в кодировке UTF-8,
    > а не массив с костыл^W набором чаров)

    Если убрать малознакомые мне слова и попытки манипулировать, то правильно ли я понимаю, что тут написано о невозможности обработать массив октетов средствами Раста? (но этого не может быть).

     
     
  • 5.82, Аноним. (?), 13:32, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Свое не пахнет Тут написано о том, что строки в расте совсем другие А тепер... большой текст свёрнут, показать
     
     
  • 6.87, n00by (ok), 14:14, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    gt оверквотинг удален Предлагаю перечитать сообщение, на которое Вы отвечали ... большой текст свёрнут, показать
     
     
  • 7.92, Аноним (92), 14:47, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >> но нашёл вот это:
    >> pub unsafe extern "C" fn strlen(cs: *const c_char) -> size_t
    >> что бы я спросил: а зачем?
    > Предлагаю перечитать сообщение, на которое Вы отвечали. Там был задан вопрос на
    > эту тему. Если не понятно, что такое Бойер-Мур, поищите в сети.
    > Если Вы не готовы дать ответ не мой вопрос, не тратьте
    > время.

    Предлагаю перестать читать жопой и юлить и ответить наконец на вопрос: на*ера обязательно нужно велосипедить свою реализацию операции над _чужим_ типом данных? Что бы что?

     
     
  • 8.125, n00by (ok), 07:13, 18/06/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    То есть я сам должен ответить свой на вопрос, зачем Rust strlen Не проблема, ... текст свёрнут, показать
     
  • 3.57, Аноним (57), 22:09, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    strlen действительно могли бы реализовать сами,  но может быть,  нужен и конкретно текущей libc. А без malloc нельзя было бы работать с теми кривыми сишными поделиями, которым подай аллоцированное, а освободят они сами естественно сишным free
     
     
  • 4.67, n00by (ok), 07:01, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > strlen действительно могли бы реализовать сами,  но может быть,  нужен
    > и конкретно текущей libc.

    Зачем? Вызов внешней функции существенно дороже, чем встроенный (inline) подсчёт.

    > А без malloc нельзя было бы работать
    > с теми кривыми сишными поделиями, которым подай аллоцированное, а освободят они
    > сами естественно сишным free

    Не согласен с формулировкой. Можно. Да, для этого придётся переписать malloc на Rust и следить за изменениями эталонной реализации. Либо перехватывать вызовы free(). Это решаемая задача, но в данном случае трудозатраты вряд ли оправданы, как в случае со strlen().

     
     
  • 5.69, боня (?), 07:21, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    как вариант это просто автогенерированный код
     
     
  • 6.70, n00by (ok), 07:30, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > как вариант это просто автогенерированный код

    Спасибо. Это разумный вариант.

     
  • 5.120, Аноним (120), 01:42, 18/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    И очень сильно и сложно приседать, чтобы ничего не ломалось при LD_PRELOAD, скажем, jemalloc, по сути вызывая написанный на расте код через FFI.
    И это уже в одном шаге от переписывания libc на раст. Что на самом деле идея красивая но неосуществимая, ведь glibc ужасает не только качеством но и объемом кода
     
     
  • 6.124, n00by (ok), 07:10, 18/06/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > И очень сильно и сложно приседать, чтобы ничего не ломалось при LD_PRELOAD,
    > скажем, jemalloc, по сути вызывая написанный на расте код через FFI.

    Это не эквивалентно "нельзя".

    > И это уже в одном шаге от переписывания libc на раст. Что
    > на самом деле идея красивая но неосуществимая, ведь glibc ужасает не
    > только качеством но и объемом кода

    Но Си ведь небезопасный язык. Значит libc небезопасна. Следовало переписать сначала её, а потом уже всё остальное.

     
  • 2.31, Аноним (-), 18:34, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто бы сомневался что всё равно без libc ничего не могут. Хипстеры такие хипстеры.

    https://man7.org/linux/man-pages/man2/syscalls.2.html
    >> System calls are generally not invoked directly, but rather via
    >> wrapper functions in glibc (or perhaps some other library).

    Кто бы сомневался, что жопоскриптозники в вопросе разбираются как козы в апельсинах?

     
     
  • 3.32, n00by (ok), 18:42, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Поскольку разбираетесь, подскажите, пожалуйста, вокруг какого syscall является обёрткой функция

    pub unsafe extern "C" fn strlen(cs: *const c_char) -> size_t

    https://docs.rs/libc/0.2.97/libc/fn.strlen.html

     
     
  • 4.34, Аноним (-), 18:57, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Поскольку разбираетесь, подскажите, пожалуйста, вокруг какого syscall является обёрткой функция
    > pub unsafe extern "C" fn strlen(cs: *const c_char) -> size_t
    > https://docs.rs/libc/0.2.97/libc/fn.strlen.html
    > Raw FFI bindings to platforms’ system libraries

    Не юродствуй.
    С чего бы делать обертку неполной? Чтобы на опеннете могли поныть "Ха, хипстиры ниасилили даже обертку!1"?

     
     
  • 5.39, Прорыв_запарты_фелиал (ok), 21:16, 16/06/2021 Скрыто модератором
  • +1 +/
     
     
  • 6.45, Аноним (-), 21:34, 16/06/2021 Скрыто модератором
  • +/
     
     
  • 7.49, Прорыв_запарты_фелиал (ok), 21:41, 16/06/2021 Скрыто модератором
  • +/
     
     
  • 8.52, Аноним (-), 22:02, 16/06/2021 Скрыто модератором
  • +/
     
  • 8.68, n00by (ok), 07:07, 17/06/2021 Скрыто модератором
  • +/
     
     
  • 9.107, Прорыв_запарты_фелиал (ok), 20:34, 17/06/2021 Скрыто модератором
  • +/
     
     
  • 10.127, n00by (ok), 08:00, 18/06/2021 Скрыто модератором
  • +/
     
     
  • 11.151, Прорыв_запарты_фелиал (ok), 22:45, 24/06/2021 Скрыто модератором
  • +/
     
     
  • 12.152, n00by (ok), 07:50, 25/06/2021 Скрыто модератором
  • +/
     
  • 5.66, n00by (ok), 07:00, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Поскольку разбираетесь, подскажите, пожалуйста, вокруг какого syscall является обёрткой функция
    >> pub unsafe extern "C" fn strlen(cs: *const c_char) -> size_t
    >> https://docs.rs/libc/0.2.97/libc/fn.strlen.html
    >> Raw FFI bindings to platforms’ system libraries
    > Не юродствуй.
    > С чего бы делать обертку неполной?

    Раз не подскажете номер вызова, значит strlen() не имеет отношения к обёртке, как и попытка передёрнуть -- смысла.

    > Чтобы на опеннете могли поныть "Ха,
    > хипстиры ниасилили даже обертку!1"?

    Пока приходится ныть об уровне аргументации и качестве риторики.

     
     
  • 6.83, Аноним. (?), 13:38, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Раз не подскажете номер вызова, значит strlen() не имеет отношения к обёртке,
    > как и попытка передёрнуть -- смысла.

    Твоя попытка передерга - тоже. Ну или ты можешь показать, где в сабже используется strlen?

    >> всё равно без libc ничего не могут. Хипстеры такие хипстеры.
    > Пока приходится ныть об уровне аргументации и качестве риторики.

    О да.


     
     
  • 7.88, n00by (ok), 14:20, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Раз не подскажете номер вызова, значит strlen() не имеет отношения к обёртке,
    >> как и попытка передёрнуть -- смысла.
    > Твоя попытка передерга - тоже. Ну или ты можешь показать, где в
    > сабже используется strlen?

    Могу назвать вопрос унылой демагогией. Бремя доказательства, что strlen() является "System call ... wrapper function", лежит на заявителе.


     
     
  • 8.90, Аноним (-), 14:26, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В смысле, вставить от балды не используемый сабжем strlen и требовать доказать... текст свёрнут, показать
     
     
  • 9.109, Прорыв_запарты_фелиал (ok), 20:44, 17/06/2021 Скрыто модератором
  • –1 +/
     
  • 3.75, Урри (ok), 11:20, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    translate.google.com <- "generally"

    Это в тему коз и апельсинов.

     
     
  • 4.84, Аноним. (?), 13:51, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > translate.google.com <- "generally"
    > Это в тему коз и апельсинов.

    Так ты коза, дергаящая в своих программах сисколы напрямую?
    Или очередной опеннетный апельсин-теоретик, который любит поныть (в зависимости от темы) "Пачему оно тянет еще один жирный рантай, не используя системное!© Зачем переписали?" и "А-а-а! Используют системное! Не осилили свое! Фууу!"?

     
     
  • 5.89, n00by (ok), 14:24, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А что, из Rust нельзя дёрнуть сискол напрямую? Скажите, Вас кто-то нанял, что бы Вы сливали столь популярный и многообещающий язык, или оно само так получается?
     
     
  • 6.91, Аноним (92), 14:40, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Логика уровня А что, из С нельзя дернуть сискол напрямую или почему так никто... большой текст свёрнут, показать
     
     
  • 7.108, Прорыв_запарты_фелиал (ok), 20:39, 17/06/2021 Скрыто модератором
  • +/
     
  • 7.126, n00by (ok), 07:49, 18/06/2021 Скрыто модератором
  • –2 +/
     
     
  • 8.128, Аноним (-), 12:11, 18/06/2021 Скрыто модератором
  • +/
     
     
  • 9.136, n00by (ok), 16:28, 18/06/2021 Скрыто модератором
  • +/
     

     ....ответы скрыты модератором (38)

  • 1.29, Алексей (??), 18:12, 16/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Aya не использует libbpf и компилятор bcc,

    Начали за здравие...

    > а предлагает собственную реализацию, написанную на Rust

    ... у которого под капотом тот же llvm, что и у bcc. Закончили за упокой.

     
     
  • 2.33, Аноним (-), 18:45, 16/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > компилятор bcc,
    >>  llvm-bpf backend
    > Начали за здравие...

    Очередной опеннетный комментатор начал за здравие
    >> а предлагает собственную реализацию, написанную на Rust
    >> [b]pure Rust implementation[/b]
    > ... у которого под капотом тот же llvm, что и у bcc. Закончили за упокой.

    А кончил посадкой в лужу ...

     
     
  • 3.40, Прорыв_запарты_фелиал (ok), 21:19, 16/06/2021 Скрыто модератором
  • +/
     

  • 1.44, Аноним (44), 21:28, 16/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Очередное никому ненужное, недоделанное и глючное поделье на rust
     
     
  • 2.131, burjui (ok), 13:19, 18/06/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ненужное онаниму с Опеннета и, конечно же, им лично не протестированное, что позволяет ему смело испражняться в комментах с умным видом. Ведь, если тебе поставили плюсики, ты автоматически прав.
     
     
  • 3.133, Аноним (-), 13:35, 18/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ведь, если сам себе поставил плюсики, ты автоматически прав.

    Пофиксил.


     
     
  • 4.135, burjui (ok), 15:58, 18/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Поставил тебе плюсик, но после твоих слов никто не поверит, что это сделал не ты сам. То есть, я только что дискредитировал тебя как союзника в дебатах just for fun. Хотя, кто знает - может, это был не ты, а тот, первый Аноним, который специально хотел, чтобы все подумали, будто он сам себе их поставил, чтобы дискредитировать идею своего первого комментария. Многоходовочка, получается.
     

  • 1.59, Аноним (59), 22:20, 16/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Каждый раз после прочтения комментариев анонимных экспертов с opennet начинаю ненавидеть rust всей душой. Понимаю что комментарии глупейшие, но всё равно читаю :-(
     
     
  • 2.76, Урри (ok), 11:22, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А я - любить. Столько лулзов еще ни один язык не доставлял.

    Писать на нем, само собой, я не планирую (мне моя психика дороже), но наслаждаться подгорающими жепками анонимов с обеих сторон баррикад - бесценно.

     

  • 1.62, растоманам надо (?), 22:31, 16/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    писать на сишарпе, там тоже есть ансейф.
     
  • 1.72, Annoynymous (ok), 08:57, 17/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Linux поддерживает 15 архитектур и что-то около сотни микроархитектур.

    Компилятор Rust поддерживает что-то около 9 архитектур.

    Добавление Rust в ядро сократит число поддерживаемых линуксом архитектур.

     
     
  • 2.94, Аноним (94), 16:05, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На нем планируют писать драйверы. Драйвер и так практически всегда прибиты к одной или двум архитектурам. Так что ничего не сломается на неподдерживаемых. Потому что оно на них и не работало))
     
     
  • 3.96, Annoynymous (ok), 16:23, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > "Представлена библиотека Aya для создания eBPF-обработчиков
    > На нем планируют писать драйверы.

    Ты бы читал тему, прежде чем комментировать, а то складывается впечатление, что ты читаешь набор ключевых слов и отвечаешь исходя из их наличия.

     
     
  • 4.102, Аноним (102), 18:08, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    это типа намек на то, что ebpf обработчики на расте не будут работать на платформах, не поддерживаемх им? с чего бы это? ebpf это виртуальная машина, берешь и собираешь свои обработчики на нужном железе под эту виртуальную машину, запускаешь на всех железках
     
     
  • 5.113, deeaitch (ok), 21:03, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > ebpf это виртуальная машина

    Нет. Почитай внимательней

     
     
  • 6.117, Аноним (102), 00:35, 18/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > позволяющей создавать на языке Rust обработчики eBPF, запускаемые внутри ядра Linux в специальной виртуальной машине с JIT

    прочитал

     
     
  • 7.118, deeaitch (ok), 01:18, 18/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >> позволяющей создавать на языке Rust обработчики eBPF, запускаемые внутри ядра Linux в специальной виртуальной машине с JIT
    > прочитал

    Теперь прочитай что такое JIT и типы виртуализации

     
     
  • 8.145, Аноним (102), 22:04, 18/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Прочитал и мнение не поменял Давай короче, с пруфами, раз такой умный... текст свёрнут, показать
     
  • 8.149, Аноним (149), 00:30, 24/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Автор камента реально похоже не понимает что такое JIT Виртуальная машина всег... текст свёрнут, показать
     
     
  • 9.150, n00by (ok), 07:53, 24/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Я не понимаю, что такое JIT Но кое-что слышал про just-in-time compiler Он так... текст свёрнут, показать
     
  • 4.104, Аноним (94), 19:49, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это же не выпиливание имеющихся компиляторов и замена на этот. На неподдерживаемых платформах просто не будешь писать обработчики на расте, а будешь по-старинке. И уже написанные тоже никуда не исчезнут.
    Т.о. те кто хочет писать на расте получат эту возможность, а те кто не хочет - даже не заметят.
     
     
  • 5.115, deeaitch (ok), 21:04, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Т.о. те кто хочет писать на расте получат эту возможность

    Пока ещё не получат. До получат там пилить и пилить. К тому времени оно и здохнуть может.

     
  • 2.95, Аноним (94), 16:12, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вообще немного больше чем 9. Подробнее можно почитать тут https://doc.rust-lang.org/nightly/rustc/platform-support.html
    Плюс - а какие из недостающих восьми реально где-то используются, а не являются окаменевшим говном мамонтов которое тащут только из-за пары корпораций?
     
     
  • 3.97, Annoynymous (ok), 16:24, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вообще немного больше чем 9. Подробнее можно почитать тут https://doc.rust-lang.org/nightly/rustc/platform-support.html
    > Плюс - а какие из недостающих восьми реально где-то используются, а не
    > являются окаменевшим говном мамонтов которое тащут только из-за пары корпораций?

    В любом случае, добавление Rust в ядро сокращает количество поддерживаемых архитектур. А это не есть карашо.

     
     
  • 4.101, Аноним (94), 17:28, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Странная логика.
    Linux 5.10 LTS дропнул поддержку больше десятка платформ (подробнее тут https://www.phoronix.com/scan.php?page=news_item&px=2021-Linux-Drop-Old-CPUs) и еще больше собираются дропнуть.
    Это тоже "не есть карашо"? Или это "это другое"?
     
     
  • 5.103, Annoynymous (ok), 18:22, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Это тоже "не есть карашо"? Или это "это другое"?

    Да. А почему странная?

     
  • 3.99, noxyu (?), 16:59, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >Плюс - а какие из недостающих восьми реально где-то используются, а не являются окаменевшим говном мамонтов которое тащут только из-за пары корпораций?

    Предлагаю поддерживать только wintel, всё остальное маргинально.

     
     
  • 4.100, Аноним (94), 17:23, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ну зачем себя так ограничивать - там есть еще ARM, MIPS, RISC-V и куча других.
    Любители старенького могут выбрать PPC или S390x. Так что есть из чего выбирать!

    А какой-то M32R который дропнули даже в линуксе никто нафиг не сдался. И там есть еще куча аналогичных архитектур, которые только формально поддерживаются.

     

  • 1.77, YetAnotherOnanym (ok), 12:03, 17/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Это выведет ядро Линуха на новый уровень навороченности и замороченности.
     
     
  • 2.106, балмер в маске V (?), 20:15, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И зависимости от кого надо
     

  • 1.78, Fractal cucumber (ok), 12:10, 17/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Хорошо, наверное, что начали появляться готовые проекты на расте...
     
     
  • 2.98, Аноним (98), 16:45, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >готовые проекты на расте
    >
    >API ещё не стабилизирован

    Тонко! И в этом вся суть "готовых" растовых проектов.

     
     
  • 3.153, freecoder (?), 22:28, 03/07/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А что вообще есть у нас готового, что не будет доработано или исправлено?
     
  • 2.110, deeaitch (ok), 20:56, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    К сожалению или к счатью не мне нудить. Но нет, не готовые. Сырое оно как гавно мамонта.
     

  • 1.105, балмер в маске V (?), 20:15, 17/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Всем радетелям за новое безопасное рекомендую уточнитт, кто владеет crates.io - сюрприз гарантирую
     
     
  • 2.114, Аноним (114), 21:04, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Rust Fondation?
     
  • 2.116, Аноним (-), 22:56, 17/06/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Всем радетелям за новое безопасное рекомендую уточнитт, кто владеет crates.io - сюрприз  гарантирую

    То ли дело Владетель kernel.org, да?
    > Registrant Organization: The Linux Foundation

    https://www.linuxfoundation.org/about/board/
    MICROSOFT
    ORACLE
    AT&T
    FACEBOOK
    IBM
    HUAWEI
    INTEL
    Или как обычно, "это другое!"?

     

  • 1.119, Аноним (119), 01:35, 18/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Единственный плюс раста это уродливый и упоротый цэпэпэ который от стандарта в стандарт становится размером с глобус и при этом тянет с собой сишные костыли и подпорки... это жк наверное случится и растом если он когда нибудь взлетит, но потом...

    В любом случае по уродливости и упоротости синтаксиса раст занимает почетное второе место сразу за крестами

     
  • 1.121, Аноним (119), 01:42, 18/06/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Почему нельзя было пилить синтаксис раста с оглядкой не на наркоманский CPP, а на более адекватный C# ну или Java на худой конец? И я не говорю о реализации языка, а о синтаксисе! Синтаксис можно было человеческий сделать?
     
     
  • 2.132, burjui (ok), 13:33, 18/06/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Здешнее нытьё про синтаксис уже начинает утомлять. Без семантики синтаксис не имеет смысла, вот и учите её - тогда придёт навык чтения, и все проблемы отпадут. Такое ощущение, будто половина опеннетчиков остановилась в профессиональном развитии и категорически не приемлет изменений в привычном порядке вещей. И с какой стати он вдруг стал похож на C++? Это, скорее, ML в сишной обёртке, со своей спецификой. Если тебе нужен синтаксис, как в C# или Java, то и пиши тогда на них, и забей на Rust. Новые ЯП появляются не для того, чтобы делать всё по-старому. Новая семантика - новый синтаксис.

    TL;DR
    Синтаксис уже человеческий, просто некоторым человекам лень перестраивать мышление.

     
     
  • 3.146, Аноним (146), 21:11, 19/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Синтаксис жуть криповая, это тебе любой скажет покажи ты ему код на расте... даже в крестах если не юзать в нем сишную хрень типа указателей, си-строк, макросов выглядит на порядок лучше и читабельней
     
     
  • 4.147, burjui (ok), 01:37, 20/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, если для тебя код на С++ читабельнее, то я рад, что не являюсь твоим коллегой. И, кстати, "выглядит лучше" и "читабельнее" - синонимы. Как по мне, незамеченная тобой тавтология - признак того, что ты пытаешься в этом убедить не только меня, но и себя. Впрочем, я не исключаю возможности в один прекрасный день увидеть плюсовой код, который я счёл бы читабельным. Жаль только, что плюсовики всё никак не договорятся о стиле кода, а и без того раздутый стандарт языка только разрастается с каждой итерацией, заставляя задействовать все доступные ресурсы мозга при чтении любого мало-мальски нетривиального кода, чтобы не упустить мелкие, но очень важные детали самой запутанной семантики, которую только можно найти в мире ЯП.
     
     
  • 5.148, Аноним (148), 20:43, 23/06/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Читать научись... если тебе попадался C++ на макросах и указателях на указатели то это не плюсы, это си стайл
     
  • 2.154, freecoder (?), 22:56, 03/07/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ответ есть в этой статье: https://habr.com/ru/post/532660/
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру