The OpenNET Project / Index page

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



"Представлена библиотека Aya для создания eBPF-обработчиков на языке Rust"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Представлена библиотека Aya для создания eBPF-обработчиков на языке Rust"  +/
Сообщение от opennews (ok), 16-Июн-21, 10:39 
Представлен первый выпуск библиотеки Aya, позволяющей создавать на языке Rust обработчики eBPF, запускаемые внутри ядра Linux в специальной виртуальной машине с JIT. В отличие от других инструментов для разработки eBPF-программ, Aya  не использует libbpf  и компилятор bcc, а предлагает собственную реализацию, написанную на  Rust, которая использует crate-пакет libc для прямого обращения к системным вызовам ядра. Для сборки Aya не требуется наличие инструментария для языка C и заголовочных файлов ядра. Код библиотеки распространяется под лицензиями  MIT и Apache 2.0...

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

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от lockywolf (ok), 16-Июн-21, 10:39 
И как у этого crate с thread safety?
Ответить | Правка | Наверх | Cообщить модератору

7. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от Ordu (ok), 16-Июн-21, 11:24 
Как обычно, надо полагать. Data race исключаются как класс, пока ты не прибегаешь к unsafe, а остальное всё в твоих руках. А почему ты спрашиваешь? Есть основания полагать, что у него ситуация с thread-safety отличается от дефолтной в расте?
Ответить | Правка | Наверх | Cообщить модератору

14. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от lockywolf (ok), 16-Июн-21, 12:14 
> Как обычно, надо полагать. Data race исключаются как класс, пока ты не
> прибегаешь к unsafe, а остальное всё в твоих руках. А почему
> ты спрашиваешь? Есть основания полагать, что у него ситуация с thread-safety
> отличается от дефолтной в расте?

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

Ответить | Правка | Наверх | Cообщить модератору

15. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Ordu (ok), 16-Июн-21, 12:38 
> Ну, я помню смешные курьёзы с errno, который в стандарте переменная, но
> для thread-safety сделано как макрос, разворачивающийся в вызов функции.

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

19. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (19), 16-Июн-21, 13:29 
```
__thread int errno;                                                            
extern __thread int __libc_errno __attribute__ ((alias ("errno"))) attribute_hidden;
```
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

38. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  –4 +/
Сообщение от Прорыв_запарты_фелиал (ok), 16-Июн-21, 20:59 
А вот и жертвы пропаганды нарисовались. Модель памяти раста не предполагает конкурентного доступа, а когда нет конкурентного доступа нет гонок. Тебя обманули. Меньше лозунгов ретранслируй и больше тему изучай.

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

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

41. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +6 +/
Сообщение от Ordu (ok), 16-Июн-21, 21:20 
> А вот и жертвы пропаганды нарисовались. Модель памяти раста не предполагает конкурентного
> доступа, а когда нет конкурентного доступа нет гонок.

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

Ответить | Правка | Наверх | Cообщить модератору

46. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Прорыв_запарты_фелиал (ok), 16-Июн-21, 21:36 
>race condition в расте делается элементарно. Сделай два mutex'а, и попробуй залочить их оба последовательно из параллельных потоков.

Раст не умеет в mutex - он не реализуется на расте. Это раз. Два - мутекс это не конкурентный доступ. Это костыль, который делает из конкурентного неконкурентный.

К тому же, даже если обернуть ворованный сишный мутекс в фейковое safe, то это не будет работать. Конкурентного доступа всё равно не будет. Т.е. обращаться ты сможешь только через глобальный мутекс. Это уже не гарантия раста, а гарантия рантайма. И повторю - ссылку можно получить только при захвате мутекса, а значит никакого конкурентного доступа нет. Доступ есть только к мутексу, который вопрованный сишный.

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

Ещё раз - тебя поимела пропаганда. Никакие data race в расте не делаются. Гонка предполагает шаринг, а наличие шаринга в расте - это уб. Шаринг возможен только в ворованных llvm-ir-указателях, которые нельзя обернуть в safe. Потому как это другая модель памяти, отличная от раста.

Давай ещё раз. Раст не даёт возможность шарить данные, а если не шарить данные гонок нет. Поэтому попытка написать шаринг на расте продуцирует невозможность.


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

Нет, никакая эта херня не имеет никакого отношения к языку. Всё это ансейф-хаки не выражаемые на расте. То, что она валяются в stdlib - причина одна. Любая скриптуха не способна выразить свою stdlib, поэтому эта stdlib всегда пишется на отдельном языке.

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

Зачем мне куда-то заглядывать, если я, в отличии от жертвы пропаганды, понимаю модель памяти используемую растом. И, очевидно, могу вывести из неё возможное и невозможное. Мне ненужна для этого табличка для дошколят с готовыми ответами.


Ответить | Правка | Наверх | Cообщить модератору

60. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от zig (??), 16-Июн-21, 22:23 
Братишка, напиши про zig, а то чет его тут пеарят.
Ответить | Правка | Наверх | Cообщить модератору

64. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от Аноним (64), 17-Июн-21, 02:12 
Я пиарил. Хотел на нём базу данных написать. Я руками его не трогал, но документацию и статьи внимательно прочитал.

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

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

Ответить | Правка | Наверх | Cообщить модератору

63. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +5 +/
Сообщение от Ordu (ok), 16-Июн-21, 22:33 
>>race condition в расте делается элементарно. Сделай два mutex'а, и попробуй залочить их оба последовательно из параллельных потоков.
> Раст не умеет в mutex - он не реализуется на расте. Это
> раз. Два - мутекс это не конкурентный доступ. Это костыль, который
> делает из конкурентного неконкурентный.

Да-да, точно, и массивов в расте нет, потому что они реализуются на расте.

> К тому же, даже если обернуть ворованный сишный мутекс в фейковое safe,
> то это не будет работать. Конкурентного доступа всё равно не будет.
> Т.е. обращаться ты сможешь только через глобальный мутекс.

Что значит "глобальный мьютекс"? Мьютекс в расте -- это часть типа. Если я пишу Mutex<Vec<f32>>, то это тип, который можно прочитать, например, так: прикрытый мьютексом динамический массив 32-битных флоатов. Где здесь "глобальность мьютекса"?

> Это уже не гарантия раста, а гарантия рантайма.

Эмм, да. А в чём разница? Сколь-нибудь практически полезный конкурентный доступ невозможен без гарантий рантайма.

> И повторю - ссылку можно получить
> только при захвате мутекса, а значит никакого конкурентного доступа нет.

Если ты так говоришь... нуок. И чё, теперь? Нахрен кому нужен твой конкурентный доступ, если он приводит к датарейсам?

> Доступ есть только к мутексу, который вопрованный сишный.

В сях мьютексы уворованны из ассемблера. То есть, некоторые компиляторы могут иметь вендор-специфичные builtin'ы, навроде cmpxchg или там atomic_increment, или что-нибудь типа. Но это не стандарт C, это вендорспецифичная штука. А вообще это делается inline-асмом. C просто не имеет атомарных операций, необходимых для реализации примитивов синхронизации, типа cmpxchg. В расте они, кстати, предоставляются builtin'ами, и часть стандартной библиотеки. https://doc.rust-lang.org/std/sync/atomic/index.html

>>data race в расте элементарно не делается, unsafe нужен, как раз в силу этой самой модели памяти.
> Ещё раз - тебя поимела пропаганда. Никакие data race в расте не
> делаются.

Ну, я как бы и том и говорю, что не делаются. Я не понимаю с чем или с кем ты споришь сейчас. Я о том же говорю, что data race не делаются. Я говорю, что race-condition делаются легко.

> Гонка предполагает шаринг, а наличие шаринга в расте - это
> уб.

Нет, не-Sync шаринг -- это UB. Sync значения вполне можно шарить, и Mutex тому библиотечный пример.

> Давай ещё раз. Раст не даёт возможность шарить данные, а если не
> шарить данные гонок нет. Поэтому попытка написать шаринг на расте продуцирует
> невозможность.

Ты можешь повторять это по десять раз каждый день на сон грядущий. От этого шаринг из раста никуда не денется.

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

Враньё. std лиспа написан на лиспе. std C написан на C. std раста написан на расте. Ну, C и раст наверное нельзя включить в категорию "скриптуха", но лисп прям таким просится туда.

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

А я не понимаю. Я даже не понимаю, что ты имеешь в виду под "моделью памяти". Что за модель памяти? Что-то типа RAM, EM, VAT[1]? Нет, наверное, это всё ж теоретические модели памяти _машины_, а не языка. Или что-то типа этого[2]? Не мог бы ты поделиться ссылкой, на тот теоретический фреймворк, в который позволяет тебе выстроить модель памяти раста?

[1] https://core.ac.uk/download/pdf/18462805.pdf
[2] http://canonical.org/~kragen/memory-models/

Но в любом случае, я скажу тебе одну простую вещь: любая "модель" -- это лишь модель. То есть теория, которая игнорирует существенную часть реальность, для того, чтобы когнитивные дефициты теоретика не мешали бы ему думатьо проблеме. В реальности же, программы на rust не просто имеют конкурентный доступ, они налево и направо им пользуются. Да, они избегают его, потому что раст начинает хмурится. Да, когда они его используют, они стараются обходится const доступом, но это не значит, что нельзя иметь глобальную хеш-табличку символов, где можно конкурентно эти символы искать и откуда их можно конкуретно тягать.

> И, очевидно, могу вывести из неё возможное
> и невозможное.

Нет, из модели ты _по-определению_ модели не можешь вывести всего. Модель по-определению и по-построению рассматривает только некоторые свойства реальности, игнорируя все остальные. Из геометрии Евклида ты не выведешь общую теорию относительности с её пространством-временем. Хотя геометрия Евклида -- это модель пространства, в котором мы живём. Так и из модели памяти языка ты не сможешь вывести все возможные утверждения про язык. Более того, не все утверждения про язык, которые ты сможешь вывести будут применимы.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

80. Скрыто модератором  +1 +/
Сообщение от Прорыв_запарты_фелиал (ok), 17-Июн-21, 12:57 
Ответить | Правка | Наверх | Cообщить модератору

134. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (134), 18-Июн-21, 15:30 
> ... safety?

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

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  –1 +/
Сообщение от mos87 (ok), 16-Июн-21, 10:47 
прикольно бы еще напомнить что такое (e)bpf
Ответить | Правка | Наверх | Cообщить модератору

20. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (-), 16-Июн-21, 13:40 
> прикольно бы еще напомнить что такое (e)bpf

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

Ответить | Правка | Наверх | Cообщить модератору

35. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от Аноним (35), 16-Июн-21, 19:34 
>> прикольно бы еще напомнить что такое (e)bpf
> Extended BlackArch Packet Filter

не BlackArch, а Berkley

Ответить | Правка | Наверх | Cообщить модератору

36. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от yourc (?), 16-Июн-21, 19:37 
По-моему, там ирония. Но это не точно.
Ответить | Правка | Наверх | Cообщить модератору

58. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +3 +/
Сообщение от Аноним. (?), 16-Июн-21, 22:14 
>>> прикольно бы еще напомнить что такое (e)bpf
>> Extended BlackArch Packet Filter
> не BlackArch, а Berkley

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

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

85. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (85), 17-Июн-21, 14:06 
Это предыдущая версия до redhat enterprise bsd
Ответить | Правка | Наверх | Cообщить модератору

93. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (-), 17-Июн-21, 14:57 
> Это предыдущая версия до redhat enterprise bsd

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

Ответить | Правка | Наверх | Cообщить модератору

71. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от КО (?), 17-Июн-21, 08:56 
Очередной костыль, если вам так будет понятнее
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  –12 +/
Сообщение от Qwerty (??), 16-Июн-21, 10:52 
Что бы там луддиты не говорили, а всё-таки за Хрустом будущее.
Ответить | Правка | Наверх | Cообщить модератору

4. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +11 +/
Сообщение от Аноним (4), 16-Июн-21, 11:08 
Ага за джаваскриптом, луддит.
Ответить | Правка | Наверх | Cообщить модератору

11. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +3 +/
Сообщение от Аноним (11), 16-Июн-21, 12:02 
Спасибо, поржал. Продолжайте снабжать нас веселыми историями.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

17. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +3 +/
Сообщение от JackoNeillemail (?), 16-Июн-21, 13:02 
Самое страшное то, что весьма вероятно, смеяться то он будет как раз последним.
Ответить | Правка | Наверх | Cообщить модератору

24. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от Самый Лучший Гусь (?), 16-Июн-21, 16:57 
Девушки рыдают, матросы смеются, как говорится.
Ответить | Правка | Наверх | Cообщить модератору

74. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Урри (ok), 17-Июн-21, 11:17 
"А Таня была в каске и только засмеялась" (с)
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

5. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  –1 +/
Сообщение от Аноним (4), 16-Июн-21, 11:09 
Все равно потечет и будет небезопасной зачем тут раст то?
Ответить | Правка | Наверх | Cообщить модератору

6. Скрыто модератором  +13 +/
Сообщение от Аноним (6), 16-Июн-21, 11:21 
Ответить | Правка | Наверх | Cообщить модератору

9. Скрыто модератором  +1 +/
Сообщение от Аноним (9), 16-Июн-21, 11:28 
Ответить | Правка | Наверх | Cообщить модератору

12. Скрыто модератором  –2 +/
Сообщение от Lex (??), 16-Июн-21, 12:04 
Ответить | Правка | Наверх | Cообщить модератору

13. Скрыто модератором  +1 +/
Сообщение от заминированный тапок (ok), 16-Июн-21, 12:10 
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

16. Скрыто модератором  +/
Сообщение от Аноним (11), 16-Июн-21, 12:56 
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

10. Скрыто модератором  +2 +/
Сообщение от Корец (?), 16-Июн-21, 11:29 
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

8. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +5 +/
Сообщение от псевдонимус (?), 16-Июн-21, 11:24 
>апи ещё не стабилизирован

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

Ответить | Правка | Наверх | Cообщить модератору

37. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +9 +/
Сообщение от Онаним (?), 16-Июн-21, 19:50 
Да и "пока" там можно смело убирать.
Ответить | Правка | Наверх | Cообщить модератору

27. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +2 +/
Сообщение от anonymous (??), 16-Июн-21, 17:39 
Мляяя... jit в ядре, из под обычного пользователя, версия 2 - powered by rust. Дедушка Столлман, срочно, пили гпл4, проприерасты прорвались.
Ответить | Правка | Наверх | Cообщить модератору

129. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от burjui (ok), 18-Июн-21, 13:12 
Причём тут проприетарщина и GPL? У тебя каша в голове.
Ответить | Правка | Наверх | Cообщить модератору

28. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +2 +/
Сообщение от Аноним (28), 16-Июн-21, 17:54 
Кто бы сомневался что всё равно без libc ничего не могут. Хипстеры такие хипстеры.
Ответить | Правка | Наверх | Cообщить модератору

30. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от n00by (ok), 16-Июн-21, 18:13 
Хотел было спросить, зачем там

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

Ответить | Правка | Наверх | Cообщить модератору

42. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  –1 +/
Сообщение от Аноним (-), 16-Июн-21, 21:22 
> но нашёл вот это:
> 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 набором чаров)

Ответить | Правка | Наверх | Cообщить модератору

65. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от n00by (ok), 17-Июн-21, 06:52 
>> но нашёл вот это:
>> 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 набором чаров)

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

Ответить | Правка | Наверх | Cообщить модератору

82. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от Аноним. (?), 17-Июн-21, 13:32 
>>> без libc ничего не могут
>> Хотел было спросить, зачем там ... malloc ... strlen
> Если убрать малознакомые мне слова и попытки манипулировать,

Свое не пахнет?

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

Тут написано о том, что строки в расте "совсем другие".
А теперь глянь в реализацию strlen той же glibc
https://github.com/lattera/glibc/blob/master/sysdeps/x86_64/...
https://github.com/lattera/glibc/blob/master/sysdeps/arm/str...
- предлагаешь велосипедить достаточно быструю (то есть использующую SIMD, выравненное чтение и прочее) для _внешнего_ типа данных чисто из "любви к исскуству" (ну и чтобы комментаторы на опеннете могли всласть покомментировать по поводу NIH синдрома)?


Ответить | Правка | Наверх | Cообщить модератору

87. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  –1 +/
Сообщение от n00by (ok), 17-Июн-21, 14:14 
>[оверквотинг удален]
>> то правильно ли я понимаю, что тут написано о невозможности обработать массив октетов средствами Раста?
>> (но этого не может быть).
> Тут написано о том, что строки в расте "совсем другие".
> А теперь глянь в реализацию strlen той же glibc
> https://github.com/lattera/glibc/blob/master/sysdeps/x86_64/...
> https://github.com/lattera/glibc/blob/master/sysdeps/arm/str...
>  - предлагаешь велосипедить достаточно быструю (то есть использующую SIMD, выравненное
> чтение и прочее) для _внешнего_ типа данных чисто из "любви к
> исскуству" (ну и чтобы комментаторы на опеннете могли всласть покомментировать по
> поводу NIH синдрома)?

Предлагаю перечитать сообщение, на которое Вы отвечали. Там был задан вопрос на эту тему. Если не понятно, что такое Бойер-Мур, поищите в сети. Если Вы не готовы дать ответ не мой вопрос, не тратьте время.

Ответить | Правка | Наверх | Cообщить модератору

92. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (92), 17-Июн-21, 14:47 
>> но нашёл вот это:
>> pub unsafe extern "C" fn strlen(cs: *const c_char) -> size_t
>> что бы я спросил: а зачем?
> Предлагаю перечитать сообщение, на которое Вы отвечали. Там был задан вопрос на
> эту тему. Если не понятно, что такое Бойер-Мур, поищите в сети.
> Если Вы не готовы дать ответ не мой вопрос, не тратьте
> время.

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

Ответить | Правка | Наверх | Cообщить модератору

125. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  –1 +/
Сообщение от n00by (ok), 18-Июн-21, 07:13 
То есть я сам должен ответить свой на вопрос, зачем Rust strlen()? Не проблема, напишу теперь уже без намёков: strlen() в Rust не нужна.

Теперь ты расскажи, зачем ты тут нарисовался?

Ответить | Правка | Наверх | Cообщить модератору

57. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (57), 16-Июн-21, 22:09 
strlen действительно могли бы реализовать сами,  но может быть,  нужен и конкретно текущей libc. А без malloc нельзя было бы работать с теми кривыми сишными поделиями, которым подай аллоцированное, а освободят они сами естественно сишным free
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

67. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от n00by (ok), 17-Июн-21, 07:01 
> strlen действительно могли бы реализовать сами,  но может быть,  нужен
> и конкретно текущей libc.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

69. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +2 +/
Сообщение от боня (?), 17-Июн-21, 07:21 
как вариант это просто автогенерированный код
Ответить | Правка | Наверх | Cообщить модератору

70. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от n00by (ok), 17-Июн-21, 07:30 
> как вариант это просто автогенерированный код

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

Ответить | Правка | Наверх | Cообщить модератору

120. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (120), 18-Июн-21, 01:42 
И очень сильно и сложно приседать, чтобы ничего не ломалось при LD_PRELOAD, скажем, jemalloc, по сути вызывая написанный на расте код через FFI.
И это уже в одном шаге от переписывания libc на раст. Что на самом деле идея красивая но неосуществимая, ведь glibc ужасает не только качеством но и объемом кода
Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

124. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  –1 +/
Сообщение от n00by (ok), 18-Июн-21, 07:10 
> И очень сильно и сложно приседать, чтобы ничего не ломалось при LD_PRELOAD,
> скажем, jemalloc, по сути вызывая написанный на расте код через FFI.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

31. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (-), 16-Июн-21, 18:34 
> Кто бы сомневался что всё равно без 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).

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

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

32. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от n00by (ok), 16-Июн-21, 18:42 
Поскольку разбираетесь, подскажите, пожалуйста, вокруг какого syscall является обёрткой функция

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

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

Ответить | Правка | Наверх | Cообщить модератору

34. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (-), 16-Июн-21, 18:57 
> Поскольку разбираетесь, подскажите, пожалуйста, вокруг какого 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"?

Ответить | Правка | Наверх | Cообщить модератору

39. Скрыто модератором  +1 +/
Сообщение от Прорыв_запарты_фелиал (ok), 16-Июн-21, 21:16 
Ответить | Правка | Наверх | Cообщить модератору

45. Скрыто модератором  +/
Сообщение от Аноним (-), 16-Июн-21, 21:34 
Ответить | Правка | Наверх | Cообщить модератору

49. Скрыто модератором  +/
Сообщение от Прорыв_запарты_фелиал (ok), 16-Июн-21, 21:41 
Ответить | Правка | Наверх | Cообщить модератору

52. Скрыто модератором  +/
Сообщение от Аноним (-), 16-Июн-21, 22:02 
Ответить | Правка | Наверх | Cообщить модератору

68. Скрыто модератором  +/
Сообщение от n00by (ok), 17-Июн-21, 07:07 
Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

107. Скрыто модератором  +/
Сообщение от Прорыв_запарты_фелиал (ok), 17-Июн-21, 20:34 
Ответить | Правка | Наверх | Cообщить модератору

127. Скрыто модератором  +/
Сообщение от n00by (ok), 18-Июн-21, 08:00 
Ответить | Правка | Наверх | Cообщить модератору

151. Скрыто модератором  +/
Сообщение от Прорыв_запарты_фелиал (ok), 24-Июн-21, 22:45 
Ответить | Правка | Наверх | Cообщить модератору

152. Скрыто модератором  +/
Сообщение от n00by (ok), 25-Июн-21, 07:50 
Ответить | Правка | Наверх | Cообщить модератору

66. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  –1 +/
Сообщение от n00by (ok), 17-Июн-21, 07:00 
>> Поскольку разбираетесь, подскажите, пожалуйста, вокруг какого 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"?

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

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

83. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от Аноним. (?), 17-Июн-21, 13:38 
> Раз не подскажете номер вызова, значит strlen() не имеет отношения к обёртке,
> как и попытка передёрнуть -- смысла.

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

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

О да.


Ответить | Правка | Наверх | Cообщить модератору

88. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  –1 +/
Сообщение от n00by (ok), 17-Июн-21, 14:20 
>> Раз не подскажете номер вызова, значит strlen() не имеет отношения к обёртке,
>> как и попытка передёрнуть -- смысла.
> Твоя попытка передерга - тоже. Ну или ты можешь показать, где в
> сабже используется strlen?

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


Ответить | Правка | Наверх | Cообщить модератору

90. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от Аноним (-), 17-Июн-21, 14:26 
> Могу назвать вопрос унылой демагогией.

В смысле, вставить от балды не используемый сабжем "strlen" и требовать доказать что это "wrapper functions in glib" - демагогия? Согласен.

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

Бремя доказательства "всё равно без libc ничего не могут"? Несомненно!

Ответить | Правка | Наверх | Cообщить модератору

109. Скрыто модератором  –1 +/
Сообщение от Прорыв_запарты_фелиал (ok), 17-Июн-21, 20:44 
Ответить | Правка | Наверх | Cообщить модератору

75. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Урри (ok), 17-Июн-21, 11:20 
translate.google.com <- "generally"

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

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

84. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним. (?), 17-Июн-21, 13:51 
> translate.google.com <- "generally"
> Это в тему коз и апельсинов.

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

Ответить | Правка | Наверх | Cообщить модератору

89. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  –2 +/
Сообщение от n00by (ok), 17-Июн-21, 14:24 
А что, из Rust нельзя дёрнуть сискол напрямую? Скажите, Вас кто-то нанял, что бы Вы сливали столь популярный и многообещающий язык, или оно само так получается?
Ответить | Правка | Наверх | Cообщить модератору

91. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +2 +/
Сообщение от Аноним (92), 17-Июн-21, 14:40 
> А что, из Rust нельзя дёрнуть сискол напрямую?

Логика уровня "А что, из С++ нельзя дернуть сискол напрямую или почему так никто не делает?!"


https://docs.rs/syscall/0.2.1/src/syscall/platform/linux-x86...
#[inline(always)]
pub unsafe fn syscall0(n: usize) -> usize {
    let ret : usize;
    asm!("syscall" : "={rax}"(ret)
                   : "{rax}"(n)
                   : "rcx", "r11", "memory"
                   : "volatile");
    ret
}

А теперь ты мне приведешь список реальных юзерспейсных программ, дергающих сисколлы напрямую?
> Скажите, Вас кто-то нанял, что бы Вы сливали столь популярный и многообещающий язык, или оно  само так получается?

Классика впопеннетных борцунов "противорастового сопративления" - когда нечего возразить по теме, пиши глупости про "слив" ...


Ответить | Правка | Наверх | Cообщить модератору

108. Скрыто модератором  +/
Сообщение от Прорыв_запарты_фелиал (ok), 17-Июн-21, 20:39 
Ответить | Правка | Наверх | Cообщить модератору

126. Скрыто модератором  –2 +/
Сообщение от n00by (ok), 18-Июн-21, 07:49 
Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

128. Скрыто модератором  +/
Сообщение от Аноним (-), 18-Июн-21, 12:11 
Ответить | Правка | Наверх | Cообщить модератору

136. Скрыто модератором  +/
Сообщение от n00by (ok), 18-Июн-21, 16:28 
Ответить | Правка | Наверх | Cообщить модератору

29. "Заменили одну обёртку на другую"  +1 +/
Сообщение от Алексей (??), 16-Июн-21, 18:12 
> Aya не использует libbpf и компилятор bcc,

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

33. "Заменили одну обёртку на другую"  +1 +/
Сообщение от Аноним (-), 16-Июн-21, 18:45 
> компилятор bcc,
>>  llvm-bpf backend
> Начали за здравие...

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

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

Ответить | Правка | Наверх | Cообщить модератору

40. Скрыто модератором  +/
Сообщение от Прорыв_запарты_фелиал (ok), 16-Июн-21, 21:19 
Ответить | Правка | Наверх | Cообщить модератору

44. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +7 +/
Сообщение от Аноним (44), 16-Июн-21, 21:28 
Очередное никому ненужное, недоделанное и глючное поделье на rust
Ответить | Правка | Наверх | Cообщить модератору

131. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +2 +/
Сообщение от burjui (ok), 18-Июн-21, 13:19 
Ненужное онаниму с Опеннета и, конечно же, им лично не протестированное, что позволяет ему смело испражняться в комментах с умным видом. Ведь, если тебе поставили плюсики, ты автоматически прав.
Ответить | Правка | Наверх | Cообщить модератору

133. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от Аноним (-), 18-Июн-21, 13:35 
> Ведь, если сам себе поставил плюсики, ты автоматически прав.

Пофиксил.


Ответить | Правка | Наверх | Cообщить модератору

135. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от burjui (ok), 18-Июн-21, 15:58 
Поставил тебе плюсик, но после твоих слов никто не поверит, что это сделал не ты сам. То есть, я только что дискредитировал тебя как союзника в дебатах just for fun. Хотя, кто знает - может, это был не ты, а тот, первый Аноним, который специально хотел, чтобы все подумали, будто он сам себе их поставил, чтобы дискредитировать идею своего первого комментария. Многоходовочка, получается.
Ответить | Правка | Наверх | Cообщить модератору

59. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (59), 16-Июн-21, 22:20 
Каждый раз после прочтения комментариев анонимных экспертов с opennet начинаю ненавидеть rust всей душой. Понимаю что комментарии глупейшие, но всё равно читаю :-(
Ответить | Правка | Наверх | Cообщить модератору

76. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от Урри (ok), 17-Июн-21, 11:22 
А я - любить. Столько лулзов еще ни один язык не доставлял.

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

Ответить | Правка | Наверх | Cообщить модератору

62. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +2 +/
Сообщение от растоманам надо (?), 16-Июн-21, 22:31 
писать на сишарпе, там тоже есть ансейф.
Ответить | Правка | Наверх | Cообщить модератору

72. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от Annoynymous (ok), 17-Июн-21, 08:57 
Linux поддерживает 15 архитектур и что-то около сотни микроархитектур.

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

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

Ответить | Правка | Наверх | Cообщить модератору

94. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от Аноним (94), 17-Июн-21, 16:05 
На нем планируют писать драйверы. Драйвер и так практически всегда прибиты к одной или двум архитектурам. Так что ничего не сломается на неподдерживаемых. Потому что оно на них и не работало))
Ответить | Правка | Наверх | Cообщить модератору

96. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от Annoynymous (ok), 17-Июн-21, 16:23 
> "Представлена библиотека Aya для создания eBPF-обработчиков
> На нем планируют писать драйверы.

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

Ответить | Правка | Наверх | Cообщить модератору

102. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (102), 17-Июн-21, 18:08 
это типа намек на то, что ebpf обработчики на расте не будут работать на платформах, не поддерживаемх им? с чего бы это? ebpf это виртуальная машина, берешь и собираешь свои обработчики на нужном железе под эту виртуальную машину, запускаешь на всех железках
Ответить | Правка | Наверх | Cообщить модератору

113. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от deeaitch (ok), 17-Июн-21, 21:03 
> ebpf это виртуальная машина

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

Ответить | Правка | Наверх | Cообщить модератору

117. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (102), 18-Июн-21, 00:35 
> позволяющей создавать на языке Rust обработчики eBPF, запускаемые внутри ядра Linux в специальной виртуальной машине с JIT

прочитал

Ответить | Правка | Наверх | Cообщить модератору

118. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от deeaitch (ok), 18-Июн-21, 01:18 
>> позволяющей создавать на языке Rust обработчики eBPF, запускаемые внутри ядра Linux в специальной виртуальной машине с JIT
> прочитал

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

Ответить | Правка | Наверх | Cообщить модератору

145. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (102), 18-Июн-21, 22:04 
Прочитал и мнение не поменял. Давай короче, с пруфами, раз такой умный
Ответить | Правка | Наверх | Cообщить модератору

149. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (149), 24-Июн-21, 00:30 
Автор камента реально похоже не понимает что такое JIT:)

Виртуальная машина всегда остается, просто интерпретатор этой виртуальной машины более не читает байт код, а читает лишь код собранный JIT. Но виртуальная машина с ее иерархией памяти, архитектурой все остается))

Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

150. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от n00by (ok), 24-Июн-21, 07:53 
Я не понимаю, что такое JIT. Но кое-что слышал про just-in-time compiler. Он таки компилирует байт-код (то, что исполняется виртуальным процессором/машиной -- это такой большой switch/case, а не QEMU) в машинный (исполняемый непосредственно физическим процессором). Другое дело, что в некоторых реализациях компилируется не весь байт-код, а только часто вызываемый ветки -- тогда вирт.машина остаётся (она и решает, что требуется откомпилировать).
Ответить | Правка | Наверх | Cообщить модератору

104. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (94), 17-Июн-21, 19:49 
Это же не выпиливание имеющихся компиляторов и замена на этот. На неподдерживаемых платформах просто не будешь писать обработчики на расте, а будешь по-старинке. И уже написанные тоже никуда не исчезнут.
Т.о. те кто хочет писать на расте получат эту возможность, а те кто не хочет - даже не заметят.
Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

115. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от deeaitch (ok), 17-Июн-21, 21:04 
> Т.о. те кто хочет писать на расте получат эту возможность

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

Ответить | Правка | Наверх | Cообщить модератору

95. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  –1 +/
Сообщение от Аноним (94), 17-Июн-21, 16:12 
Вообще немного больше чем 9. Подробнее можно почитать тут https://doc.rust-lang.org/nightly/rustc/platform-support.html
Плюс - а какие из недостающих восьми реально где-то используются, а не являются окаменевшим говном мамонтов которое тащут только из-за пары корпораций?
Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

97. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  –1 +/
Сообщение от Annoynymous (ok), 17-Июн-21, 16:24 
> Вообще немного больше чем 9. Подробнее можно почитать тут https://doc.rust-lang.org/nightly/rustc/platform-support.html
> Плюс - а какие из недостающих восьми реально где-то используются, а не
> являются окаменевшим говном мамонтов которое тащут только из-за пары корпораций?

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

Ответить | Правка | Наверх | Cообщить модератору

101. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (94), 17-Июн-21, 17:28 
Странная логика.
Linux 5.10 LTS дропнул поддержку больше десятка платформ (подробнее тут https://www.phoronix.com/scan.php?page=news_item&px=2021-Lin... и еще больше собираются дропнуть.
Это тоже "не есть карашо"? Или это "это другое"?
Ответить | Правка | Наверх | Cообщить модератору

103. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Annoynymous (ok), 17-Июн-21, 18:22 
> Это тоже "не есть карашо"? Или это "это другое"?

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

Ответить | Правка | Наверх | Cообщить модератору

99. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от noxyu (?), 17-Июн-21, 16:59 
>Плюс - а какие из недостающих восьми реально где-то используются, а не являются окаменевшим говном мамонтов которое тащут только из-за пары корпораций?

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

Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

100. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (94), 17-Июн-21, 17:23 
Ну зачем себя так ограничивать - там есть еще ARM, MIPS, RISC-V и куча других.
Любители старенького могут выбрать PPC или S390x. Так что есть из чего выбирать!

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

Ответить | Правка | Наверх | Cообщить модератору

77. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +2 +/
Сообщение от YetAnotherOnanym (ok), 17-Июн-21, 12:03 
Это выведет ядро Линуха на новый уровень навороченности и замороченности.
Ответить | Правка | Наверх | Cообщить модератору

106. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от балмер в маске V (?), 17-Июн-21, 20:15 
И зависимости от кого надо
Ответить | Правка | Наверх | Cообщить модератору

78. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от Fractal cucumber (ok), 17-Июн-21, 12:10 
Хорошо, наверное, что начали появляться готовые проекты на расте...
Ответить | Правка | Наверх | Cообщить модератору

98. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от Аноним (98), 17-Июн-21, 16:45 
>готовые проекты на расте
>
>API ещё не стабилизирован

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

Ответить | Правка | Наверх | Cообщить модератору

153. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от freecoder (?), 03-Июл-21, 22:28 
А что вообще есть у нас готового, что не будет доработано или исправлено?
Ответить | Правка | Наверх | Cообщить модератору

110. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от deeaitch (ok), 17-Июн-21, 20:56 
К сожалению или к счатью не мне нудить. Но нет, не готовые. Сырое оно как гавно мамонта.
Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

105. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от балмер в маске V (?), 17-Июн-21, 20:15 
Всем радетелям за новое безопасное рекомендую уточнитт, кто владеет crates.io - сюрприз гарантирую
Ответить | Правка | Наверх | Cообщить модератору

114. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +1 +/
Сообщение от Аноним (114), 17-Июн-21, 21:04 
Rust Fondation?
Ответить | Правка | Наверх | Cообщить модератору

116. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +3 +/
Сообщение от Аноним (-), 17-Июн-21, 22:56 
> Всем радетелям за новое безопасное рекомендую уточнитт, кто владеет crates.io - сюрприз  гарантирую

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

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

Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

119. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (119), 18-Июн-21, 01:35 
Единственный плюс раста это уродливый и упоротый цэпэпэ который от стандарта в стандарт становится размером с глобус и при этом тянет с собой сишные костыли и подпорки... это жк наверное случится и растом если он когда нибудь взлетит, но потом...

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

Ответить | Правка | Наверх | Cообщить модератору

121. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (119), 18-Июн-21, 01:42 
Почему нельзя было пилить синтаксис раста с оглядкой не на наркоманский CPP, а на более адекватный C# ну или Java на худой конец? И я не говорю о реализации языка, а о синтаксисе! Синтаксис можно было человеческий сделать?
Ответить | Правка | Наверх | Cообщить модератору

132. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +2 +/
Сообщение от burjui (ok), 18-Июн-21, 13:33 
Здешнее нытьё про синтаксис уже начинает утомлять. Без семантики синтаксис не имеет смысла, вот и учите её - тогда придёт навык чтения, и все проблемы отпадут. Такое ощущение, будто половина опеннетчиков остановилась в профессиональном развитии и категорически не приемлет изменений в привычном порядке вещей. И с какой стати он вдруг стал похож на C++? Это, скорее, ML в сишной обёртке, со своей спецификой. Если тебе нужен синтаксис, как в C# или Java, то и пиши тогда на них, и забей на Rust. Новые ЯП появляются не для того, чтобы делать всё по-старому. Новая семантика - новый синтаксис.

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

Ответить | Правка | Наверх | Cообщить модератору

146. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (146), 19-Июн-21, 21:11 
Синтаксис жуть криповая, это тебе любой скажет покажи ты ему код на расте... даже в крестах если не юзать в нем сишную хрень типа указателей, си-строк, макросов выглядит на порядок лучше и читабельней
Ответить | Правка | Наверх | Cообщить модератору

147. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от burjui (ok), 20-Июн-21, 01:37 
Ну, если для тебя код на С++ читабельнее, то я рад, что не являюсь твоим коллегой. И, кстати, "выглядит лучше" и "читабельнее" - синонимы. Как по мне, незамеченная тобой тавтология - признак того, что ты пытаешься в этом убедить не только меня, но и себя. Впрочем, я не исключаю возможности в один прекрасный день увидеть плюсовой код, который я счёл бы читабельным. Жаль только, что плюсовики всё никак не договорятся о стиле кода, а и без того раздутый стандарт языка только разрастается с каждой итерацией, заставляя задействовать все доступные ресурсы мозга при чтении любого мало-мальски нетривиального кода, чтобы не упустить мелкие, но очень важные детали самой запутанной семантики, которую только можно найти в мире ЯП.
Ответить | Правка | Наверх | Cообщить модератору

148. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Аноним (148), 23-Июн-21, 20:43 
Читать научись... если тебе попадался C++ на макросах и указателях на указатели то это не плюсы, это си стайл
Ответить | Правка | Наверх | Cообщить модератору

155. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от Хан (?), 30-Июл-21, 00:10 
Реально так
Ответить | Правка | Наверх | Cообщить модератору

154. "Представлена библиотека Aya для создания eBPF-обработчиков н..."  +/
Сообщение от freecoder (?), 03-Июл-21, 22:56 
Ответ есть в этой статье: https://habr.com/ru/post/532660/
Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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