forum.opennet.ru - "Представлена библиотека Aya для создания eBPF-обработчиков на языке Rust" (123)

"Представлена библиотека 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.dev/opennews/art.shtml?num=55340
Ответить \| Правка \| Cообщить модератору

Оглавление

И как у этого crate с thread safety , lockywolf (ok), 10:39 , 16-Июн-21, (1) +1

Как обычно, надо полагать Data race исключаются как класс, пока ты не прибегаеш, Ordu (ok), 11:24 , 16-Июн-21, (7) +1

Ну, я помню смешные курьёзы с errno, который в стандарте переменная, но для thre, lockywolf (ok), 12:14 , 16-Июн-21, (14) +1

Чё за курьёзы Я не помню Мне было бы интересно посмотреть, как кто-то не справ, Ordu (ok), 12:38 , 16-Июн-21, (15)
__thread int errno , Аноним (19), 13:29 , 16-Июн-21, (19)

А вот и жертвы пропаганды нарисовались Модель памяти раста не предполагает конк, Прорыв_запарты_фелиал (ok), 20:59 , 16-Июн-21, (38) –4

race condition в расте делается элементарно Сделай два mutex а, и попробуй зало, Ordu (ok), 21:20 , 16-Июн-21, (41) +6

Раст не умеет в mutex - он не реализуется на расте Это раз Два - мутекс это не, Прорыв_запарты_фелиал (ok), 21:36 , 16-Июн-21, (46) +1

Братишка, напиши про zig, а то чет его тут пеарят , zig (??), 22:23 , 16-Июн-21, (60) +1

Я пиарил Хотел на нём базу данных написать Я руками его не трогал, но документ, Аноним (64), 02:12 , 17-Июн-21, (64)

buh говорит что это не так Это скорее Раст не готов в силу своей расплывчатости, Аноним (156), 23:02 , 30-Ноя-23, (156)

Да-да, точно, и массивов в расте нет, потому что они реализуются на расте Что зн, Ordu (ok), 22:33 , 16-Июн-21, (63) +5

Скрыто модератором, Прорыв_запарты_фелиал (ok), 12:57 , 17-Июн-21, (80) +1

Там где есть JIT безопасности нет , Аноним (134), 15:30 , 18-Июн-21, (134)

прикольно бы еще напомнить что такое e bpf, mos87 (ok), 10:47 , 16-Июн-21, (2) –1

Extended BlackArch Packet FilterХотя некоторые утверждают, что придумано оно был, Аноним (-), 13:40 , 16-Июн-21, (20)

не BlackArch, а Berkley, Аноним (35), 19:34 , 16-Июн-21, (35) +1

По-моему, там ирония Но это не точно , yourc (?), 19:37 , 16-Июн-21, (36)
Berkeley Linux Никогда о таком не слышал , Аноним. (?), 22:14 , 16-Июн-21, (58) +3

Это предыдущая версия до redhat enterprise bsd, Аноним (85), 14:06 , 17-Июн-21, (85)

БЗДы по определению могут только воровать из линуха Даже JIT для BPF - и тот оп, Аноним (-), 14:57 , 17-Июн-21, (93)

Очередной костыль, если вам так будет понятнее, КО (?), 08:56 , 17-Июн-21, (71)

Что бы там луддиты не говорили, а всё-таки за Хрустом будущее , Qwerty (??), 10:52 , 16-Июн-21, (3) –12

Ага за джаваскриптом, луддит , Аноним (4), 11:08 , 16-Июн-21, (4) +11
Спасибо, поржал Продолжайте снабжать нас веселыми историями , Аноним (11), 12:02 , 16-Июн-21, (11) +3

Самое страшное то, что весьма вероятно, смеяться то он будет как раз последним , JackoNeill (?), 13:02 , 16-Июн-21, (17) +3

Девушки рыдают, матросы смеются, как говорится , Самый Лучший Гусь (?), 16:57 , 16-Июн-21, (24) +1
А Таня была в каске и только засмеялась с , Урри (ok), 11:17 , 17-Июн-21, (74)

Все равно потечет и будет небезопасной зачем тут раст то , Аноним (4), 11:09 , 16-Июн-21, (5) –1
Скрыто модератором, Аноним (6), 11:21 , 16-Июн-21, (6) +13

Скрыто модератором, Аноним (9), 11:28 , 16-Июн-21, (9) +1

Скрыто модератором, Lex (??), 12:04 , 16-Июн-21, (12) –2
Скрыто модератором, заминированный тапок (ok), 12:10 , 16-Июн-21, (13) +1
Скрыто модератором, Аноним (11), 12:56 , 16-Июн-21, (16)

Скрыто модератором, Корец (?), 11:29 , 16-Июн-21, (10) +2

Для раста это нормально , псевдонимус (?), 11:24 , 16-Июн-21, (8) +5

Да и пока там можно смело убирать , Онаним (?), 19:50 , 16-Июн-21, (37) +9

Мляяя jit в ядре, из под обычного пользователя, версия 2 - powered by rust Д, anonymous (??), 17:39 , 16-Июн-21, (27) +2

Причём тут проприетарщина и GPL У тебя каша в голове , burjui (ok), 13:12 , 18-Июн-21, (129)

Кто бы сомневался что всё равно без libc ничего не могут Хипстеры такие хипстер, Аноним (28), 17:54 , 16-Июн-21, (28) +2

Хотел было спросить, зачем тамpub unsafe extern C fn malloc size size_t - , n00by (ok), 18:13 , 16-Июн-21, (30)

И чо Тебя поразило в самое сердце, что для взаимодействия с внешними либами мож, Аноним (-), 21:22 , 16-Июн-21, (42) –1

Да, меня это поразило Вы еще про Бойер-Мура напишите для строк в 2 гигабайта, ч, n00by (ok), 06:52 , 17-Июн-21, (65) +1

Свое не пахнет Тут написано о том, что строки в расте совсем другие А теперь , Аноним. (?), 13:32 , 17-Июн-21, (82) +1

gt оверквотинг удален Предлагаю перечитать сообщение, на которое Вы отвечали , n00by (ok), 14:14 , 17-Июн-21, (87) –1

Предлагаю перестать читать жопой и юлить и ответить наконец на вопрос на ера об, Аноним (92), 14:47 , 17-Июн-21, (92)

То есть я сам должен ответить свой на вопрос, зачем Rust strlen Не проблема, , n00by (ok), 07:13 , 18-Июн-21, (125) –1

strlen действительно могли бы реализовать сами, но может быть, нужен и конкрет, Аноним (57), 22:09 , 16-Июн-21, (57)

Зачем Вызов внешней функции существенно дороже, чем встроенный inline подсчёт, n00by (ok), 07:01 , 17-Июн-21, (67)

как вариант это просто автогенерированный код, боня (?), 07:21 , 17-Июн-21, (69) +2

Спасибо Это разумный вариант , n00by (ok), 07:30 , 17-Июн-21, (70)

И очень сильно и сложно приседать, чтобы ничего не ломалось при LD_PRELOAD, скаж, Аноним (120), 01:42 , 18-Июн-21, (120)

Это не эквивалентно нельзя Но Си ведь небезопасный язык Значит libc небезопас, n00by (ok), 07:10 , 18-Июн-21, (124) –1

https man7 org linux man-pages man2 syscalls 2 htmlКто бы сомневался, что жопо, Аноним (-), 18:34 , 16-Июн-21, (31)

Поскольку разбираетесь, подскажите, пожалуйста, вокруг какого syscall является о, n00by (ok), 18:42 , 16-Июн-21, (32)

Не юродствуй С чего бы делать обертку неполной Чтобы на опеннете могли поныть , Аноним (-), 18:57 , 16-Июн-21, (34)

Скрыто модератором, Прорыв_запарты_фелиал (ok), 21:16 , 16-Июн-21, (39) +1

Скрыто модератором, Аноним (-), 21:34 , 16-Июн-21, (45)

Скрыто модератором, Прорыв_запарты_фелиал (ok), 21:41 , 16-Июн-21, (49)

Скрыто модератором, Аноним (-), 22:02 , 16-Июн-21, (52)
Скрыто модератором, n00by (ok), 07:07 , 17-Июн-21, (68)

Скрыто модератором, Прорыв_запарты_фелиал (ok), 20:34 , 17-Июн-21, (107)

Скрыто модератором, n00by (ok), 08:00 , 18-Июн-21, (127)

Скрыто модератором, Прорыв_запарты_фелиал (ok), 22:45 , 24-Июн-21, (151)

Скрыто модератором, n00by (ok), 07:50 , 25-Июн-21, (152)

Раз не подскажете номер вызова, значит strlen не имеет отношения к обёртке, ка, n00by (ok), 07:00 , 17-Июн-21, (66) –1

Твоя попытка передерга - тоже Ну или ты можешь показать, где в сабже использует, Аноним. (?), 13:38 , 17-Июн-21, (83) +1

Могу назвать вопрос унылой демагогией Бремя доказательства, что strlen являет, n00by (ok), 14:20 , 17-Июн-21, (88) –1

В смысле, вставить от балды не используемый сабжем strlen и требовать доказать, Аноним (-), 14:26 , 17-Июн-21, (90) +1

Скрыто модератором, Прорыв_запарты_фелиал (ok), 20:44 , 17-Июн-21, (109) –1

translate google com - generally Это в тему коз и апельсинов , Урри (ok), 11:20 , 17-Июн-21, (75)

Так ты коза, дергаящая в своих программах сисколы напрямую Или очередной опенне, Аноним. (?), 13:51 , 17-Июн-21, (84)

А что, из Rust нельзя дёрнуть сискол напрямую Скажите, Вас кто-то нанял, что бы, n00by (ok), 14:24 , 17-Июн-21, (89) –2

Логика уровня А что, из С нельзя дернуть сискол напрямую или почему так никто, Аноним (92), 14:40 , 17-Июн-21, (91) +2

Скрыто модератором, Прорыв_запарты_фелиал (ok), 20:39 , 17-Июн-21, (108)
Скрыто модератором, n00by (ok), 07:49 , 18-Июн-21, (126) –2

Скрыто модератором, Аноним (-), 12:11 , 18-Июн-21, (128)

Скрыто модератором, n00by (ok), 16:28 , 18-Июн-21, (136)

Начали за здравие у которого под капотом тот же llvm, что и у bcc Закончи, Алексей (??), 18:12 , 16-Июн-21, (29) +1

Очередной опеннетный комментатор начал за здравиеА кончил посадкой в лужу , Аноним (-), 18:45 , 16-Июн-21, (33) +1

Скрыто модератором, Прорыв_запарты_фелиал (ok), 21:19 , 16-Июн-21, (40)

Очередное никому ненужное, недоделанное и глючное поделье на rust, Аноним (44), 21:28 , 16-Июн-21, (44) +7

Ненужное онаниму с Опеннета и, конечно же, им лично не протестированное, что поз, burjui (ok), 13:19 , 18-Июн-21, (131) +2

Пофиксил , Аноним (-), 13:35 , 18-Июн-21, (133) +1

Поставил тебе плюсик, но после твоих слов никто не поверит, что это сделал не ты, burjui (ok), 15:58 , 18-Июн-21, (135) +1

Каждый раз после прочтения комментариев анонимных экспертов с opennet начинаю не, Аноним (59), 22:20 , 16-Июн-21, (59)

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

писать на сишарпе, там тоже есть ансейф , растоманам надо (?), 22:31 , 16-Июн-21, (62) +2
Linux поддерживает 15 архитектур и что-то около сотни микроархитектур Компилятор, Annoynymous (ok), 08:57 , 17-Июн-21, (72) +1

На нем планируют писать драйверы Драйвер и так практически всегда прибиты к одн, Аноним (94), 16:05 , 17-Июн-21, (94) +1

Ты бы читал тему, прежде чем комментировать, а то складывается впечатление, что , Annoynymous (ok), 16:23 , 17-Июн-21, (96) +1

это типа намек на то, что ebpf обработчики на расте не будут работать на платфор, Аноним (102), 18:08 , 17-Июн-21, (102)

Нет Почитай внимательней, deeaitch (ok), 21:03 , 17-Июн-21, (113)

прочитал, Аноним (102), 00:35 , 18-Июн-21, (117)

Теперь прочитай что такое JIT и типы виртуализации, deeaitch (ok), 01:18 , 18-Июн-21, (118)

Прочитал и мнение не поменял Давай короче, с пруфами, раз такой умный, Аноним (102), 22:04 , 18-Июн-21, (145)
Автор камента реально похоже не понимает что такое JIT Виртуальная машина всегд, Аноним (149), 00:30 , 24-Июн-21, (149)

Я не понимаю, что такое JIT Но кое-что слышал про just-in-time compiler Он так, n00by (ok), 07:53 , 24-Июн-21, (150)

Это же не выпиливание имеющихся компиляторов и замена на этот На неподдерживаем, Аноним (94), 19:49 , 17-Июн-21, (104)

Пока ещё не получат До получат там пилить и пилить К тому времени оно и здохну, deeaitch (ok), 21:04 , 17-Июн-21, (115)

Вообще немного больше чем 9 Подробнее можно почитать тут https doc rust-lang , Аноним (94), 16:12 , 17-Июн-21, (95) –1

В любом случае, добавление Rust в ядро сокращает количество поддерживаемых архит, Annoynymous (ok), 16:24 , 17-Июн-21, (97) –1

Странная логика Linux 5 10 LTS дропнул поддержку больше десятка платформ подроб, Аноним (94), 17:28 , 17-Июн-21, (101)

Да А почему странная , Annoynymous (ok), 18:22 , 17-Июн-21, (103)

Предлагаю поддерживать только wintel, всё остальное маргинально , noxyu (?), 16:59 , 17-Июн-21, (99)

Ну зачем себя так ограничивать - там есть еще ARM, MIPS, RISC-V и куча других Л, Аноним (94), 17:23 , 17-Июн-21, (100)

Это выведет ядро Линуха на новый уровень навороченности и замороченности , YetAnotherOnanym (ok), 12:03 , 17-Июн-21, (77) +2

И зависимости от кого надо, балмер в маске V (?), 20:15 , 17-Июн-21, (106) +1

Хорошо, наверное, что начали появляться готовые проекты на расте , Fractal cucumber (ok), 12:10 , 17-Июн-21, (78) +1

Тонко И в этом вся суть готовых растовых проектов , Аноним (98), 16:45 , 17-Июн-21, (98) +1

А что вообще есть у нас готового, что не будет доработано или исправлено , freecoder (?), 22:28 , 03-Июл-21, (153)

К сожалению или к счатью не мне нудить Но нет, не готовые Сырое оно как гавно , deeaitch (ok), 20:56 , 17-Июн-21, (110)

Всем радетелям за новое безопасное рекомендую уточнитт, кто владеет crates io - , балмер в маске V (?), 20:15 , 17-Июн-21, (105) +1

Rust Fondation , Аноним (114), 21:04 , 17-Июн-21, (114) +1
То ли дело Владетель kernel org, да https www linuxfoundation org about board, Аноним (-), 22:56 , 17-Июн-21, (116) +3

Единственный плюс раста это уродливый и упоротый цэпэпэ который от стандарта в с, Аноним (119), 01:35 , 18-Июн-21, (119)
Почему нельзя было пилить синтаксис раста с оглядкой не на наркоманский CPP, а н, Аноним (119), 01:42 , 18-Июн-21, (121)

Здешнее нытьё про синтаксис уже начинает утомлять Без семантики синтаксис не им, burjui (ok), 13:33 , 18-Июн-21, (132) +2

Синтаксис жуть криповая, это тебе любой скажет покажи ты ему код на расте даж, Аноним (146), 21:11 , 19-Июн-21, (146)

Ну, если для тебя код на С читабельнее, то я рад, что не являюсь твоим коллего, burjui (ok), 01:37 , 20-Июн-21, (147) –1

Читать научись если тебе попадался C на макросах и указателях на указатели , Аноним (148), 20:43 , 23-Июн-21, (148)

Реально так, Хан (?), 00:10 , 30-Июл-21, (155)

Ответ есть в этой статье https habr com ru post 532660 , freecoder (?), 22:56 , 03-Июл-21, (154)

Сообщения [Сортировка по времени | 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-обработчиков н..." +1 +/–

Сообщение от Прорыв_запарты_фелиал (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-обработчиков н..." +/–

Сообщение от Аноним (64), 17-Июн-21, 02:12

Я пиарил. Хотел на нём базу данных написать. Я руками его не трогал, но документацию и статьи внимательно прочитал.
Стоит посмотреть GitHub Issues - сразу становится понятно что он не готов для чего-то серьёзного.
Буду писать на Rust.

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

156. "Представлена библиотека Aya для создания eBPF-обработчиков н..." +/–

Сообщение от Аноним (156), 30-Ноя-23, 23:02

buh говорит что это не так. Это скорее Раст не готов в силу своей расплывчатости и бессистемности.

Ответить | Правка | Наверх | 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

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

У говнораста, как и у любой скриптухи - нет какой-либо модели памяти. Говнораст существует только в рамках vm и его не заботит подобное.
При этом даже по части скриптухи это не всегда так, в силучая когда скриптуха является первичной по отношению к вм, то вм считается частью языка. Допустим, поэтому если взять ту же жаву - модель памяти там жавы, хотя на самом деле jvm, потому как жава этим не занимается.
А вот если взять какой-нибудь котлин, либо любую херню поверх jvm, то никакой котлин-модели-памяти не появится. Потому как скриптуха её делегирует vm, а вторичная скриптуха не определяет vm.

Вот llvm это такая же vm, которая имеет свою модель памяти. Которая, в свою очередь, определяется сишной моделью памяти. Она куда более конкретна.

В самом же говнорасте есть два языка. Это unsafe, который не более чем другой синтаксис для си. Там сишная модель памяти, многопоточности. Сишный же интероп и прочее. Если чуть более конкретней, то это обёртка над llvm-ir, вернее llvm-кодогеном. llvm даёт билдеры для функций, агрегатов, глобалов и прочего. Исключений. Того, что есть в си. Именно поэтому в гонорвасте более ничего нет.
А сам же llvm-ir - это просто более формальная версия си. Потому как реализует его и его окружение в себе.

Далее есть safe-говнораст. Это уже обёртка под unsafe, там совершенно левая модель памяти. Она в принципе памятью не занимается, а занимается ссылками. Поэтому моделью памяти её звать жирно, а зовётся так потому, что БЧ базируется именно на ней.

Сам же БЧ - это максимально примитивное дерьмом. По-сути там есть единственный инвариант. mut ref == unique ref. Это все правила.
Из них напрямую следует запрет шаринга. !mut ref == !unique ref, т.е. ридонли-шаринг. Ридонли-шаринг не считается за шаринг, потому как проблем не имеет. Там нет ни гонок ни прочей херне, о которой тебе рассказала пропаганда.
unique ref так же не может быть шарингом. Шаринг предполагает не-уникальные ссылки. Далее unique ref == mut ref, только так в говнорасте может взяться мутабельная ссылка.

Ответить | Правка | Наверх | 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 +/–

Сообщение от JackoNeill (?), 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

Новости 50 минут, а срача о ненужности раста на 300 сообщений нет. Opennet, выздоравливай.

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

9. Скрыто модератором +1 +/–

Сообщение от Аноним (9), 16-Июн-21, 11:28

видимо уже начинается стадия принятия

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

12. Скрыто модератором –2 +/–

Сообщение от Lex (??), 16-Июн-21, 12:04

А потом окажется, что все те "стадии" - навязанная чепуха( что-то типа "если есть из маленькой тарелки то наешься быстрее и меньшим количеством еды!!111" )
Или, к слову о том, что, если ребенку сделать/сказать что-то что его огорчит, он сразу или расстроится или сразу же полезет в драку

Ответить | Правка | Наверх | 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

Ещё одна жертва пропаганды. Сообщаю новость - сисколы и ядро никакой жопой не зависят от libc - её там в принципе нет. И libc - это не "platforms’ system libraries", потому как таких вообще не существует. Это "системные библиотеки" си, а не просто системные библиотеки. Да и само это понятие нелепо.

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

45. Скрыто модератором +/–

Сообщение от Аноним (-), 16-Июн-21, 21:34

> Ещё одна жертва пропаганды. Сообщаю новость - сисколы и ядро никакой жопой
> не зависят от libc - её там в принципе нет. И libc - это не "platforms’ system libraries", потому как таких вообще
> не существует. Это "системные библиотеки" си, а не просто системные библиотеки.
> Да и само это понятие нелепо.
Еще одна жертва чтения жопой, домысливания и гордого опровергания своих же домыслов.
Набор готовых сборок ржавой библиотеки для разных версий "stable API is nonsense" и *BSD ты что ли мейнтейнить будешь?
И точно-точно не будешь ныть на опеннете "Фи! Оно для чтения stdin хочет впендюрить свой рантайм вместо использования системного!"?

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

49. Скрыто модератором +/–

Сообщение от Прорыв_запарты_фелиал (ok), 16-Июн-21, 21:41

Жертва пропаганды поплыла. Тебе сообщили, что libc ненужна ни для сисколов ни для ядра. Это не говоря о том, что в переносимую либц, о который ты попытался закукарекать, сисколы в принципе не входят.
Ну и да, типичная методичка обгадившегося трепла вида "да ты будешь" - показывай где буду. Бегом.

В результате что я вижу? Блеял про сисколоы - обгадился с сисколами. начал нести какую-то херню. Это не говоря о том, что libc в принципе ненужна ни для интеропа с си ни для чего угодно. libc в этой скриптухе существует только по одной причине - скрипуха бездарная не может в системщину. Поэтому приходится весь рантайм воровать. Начиная от юзерспейс-рантайм заканчивая компилятором. В школу, позорище.

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

52. Скрыто модератором +/–

Сообщение от Аноним (-), 16-Июн-21, 22:02

> Жертва пропаганды поплыла. Тебе сообщили, что libc ненужна ни для сисколов ни
> для ядра. Это не говоря о том, что в переносимую либц,
> о который ты попытался закукарекать, сисколы в принципе не входят.
Ты опять читал жопой? Или собрался заимодействовать с ядром и ebpf без сисколов - через либастрал?
> Ну и да, типичная методичка обгадившегося трепла вида "да ты будешь" -
> показывай где буду. Бегом.
> В результате что я вижу? Блеял про сисколоы - обгадился с сисколами.
> начал нести какую-то херню.
Прочитал жопой, написаль хрень, опять прочитал жопой, опять написал хрень ...
> Это не говоря о том, что libc
> в принципе ненужна ни для интеропа с си ни для чего
> угодно. libc в этой скриптухе существует только по одной причине -
> скрипуха бездарная не может в системщину. Поэтому приходится весь рантайм воровать.
> Начиная от юзерспейс-рантайм заканчивая компилятором. В школу, позорище.
Какие бурные фантазии очередного жопочтеца ...

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

68. Скрыто модератором +/–

Сообщение от n00by (ok), 17-Июн-21, 07:07

> libc в этой скриптухе существует только по одной причине -
> скрипуха бездарная не может в системщину. Поэтому приходится весь рантайм воровать.
> Начиная от юзерспейс-рантайм
Начинаю подозревать, что это правда. Стандартную библиотеку С++ (которому Rust якобы замена) возможно реализовать на С++ (+ вызовы ядра) а libc сделать вокруг неё обёрткой.
> заканчивая компилятором.
Всё же компилятор это не столь простая часть, как системная библиотека. Разумно использовать готовый для экономии времени и потенциальной поддержки новых архитектур.

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

107. Скрыто модератором +/–

Сообщение от Прорыв_запарты_фелиал (ok), 17-Июн-21, 20:34

>Начинаю подозревать, что это правда. Стандартную библиотеку С++ (которому Rust якобы замена) возможно реализовать на С++ (+ вызовы ядра) а libc сделать вокруг неё обёрткой.
C++ является си, поэтому здесь нет никаких проблем. Проблема не в том, что какая-то скриптуха берёт что-то у си. Проблема в том, что эта помойная скриптуха декларирует свою самодостаточность и в принципе ортогональность с си.
>Всё же компилятор это не столь простая часть, как системная библиотека. Разумно использовать готовый для экономии времени и потенциальной поддержки новых архитектур.
Нет, это подход дерьма. У всех адекватных языков есть свой компилятор. Это основа любого языка. И компилятора у скриптухи этой позорной нет не потому, чтобы что-то упростить - это сказки для бедных. А потому что языка в принципе нет.
Вот выше там сектанты помойные спорили со мною на эту тему. Ты просто иди и посмотрим что в си есть, чтобы быть языком. Это и модель памяти и модель многопоточность и модель исполнения. Ничего этого в этой позорной скриптухе нет и никогда не будет. И именно это, в первую очередь, эти бездарности воруют, а не какие-то "новые архитектуры". Тебя просто обманули.

Полноценный язык должен являться первичным. Очевидно, что очень просто оттрансировать своё дерьмо в си, ведь ненужно ни о чём думать. А ещё лучше когда уже есть готовый кодогенратор в си(llvm и есть тот самый кодогенератор. Т.е. этот бездарный огрызок сам даже ir не генерирует).
Но в чём проблема? Проблема в том, что ты становишься заложником чужой воли. Ты будешь исполнятся так, как нужно не тебе. И если ты захочешь пойти против - не сможешь. Вот си первичен по отношению к ллвм, ллвм сделан сишниками и так, как нужно сям.
Предположим, что если завтра в си введут изменения, которые потребуют изменения в llvm такого, что это поломает говнораст - всем будет похрен на говнораст.

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

127. Скрыто модератором +/–

Сообщение от n00by (ok), 18-Июн-21, 08:00

Не вижу проблем с трансляцией в Си, когда речь идёт о каком-нибудь Vala. Более того, я не знаю, зачем там свой компилятор. Но там авторы честно обозначили, что они сделали некий продвинутый препроцессор для упрощения формошлёпства, а не очередного убийцу Си.

Ответить | Правка | Наверх | 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

>Бремя доказательства "всё равно без libc ничего не могут"? Несомненно!
Срочно в школу, клоун. Не могут не требует доказательств. Как и "не существует". Ты настолько бездарность, что даже правильно методичку использовать не может.
Бремя доказательств не работает так, как ты блеешь. Оно касается не того, кто заявляет, а того, кто что-то заявляет. Утверждающий это не тот, кто выдвигает тезис, а тот кто выдвигает тезис утверждающий существование чего-то.

Ответить | Правка | Наверх | 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

>Логика уровня "А что, из С++ нельзя дернуть сискол напрямую или почему так никто не делает?!"
Жертва пропаганды, С++ итак дёргает сисколы напрямую.
```
    asm!("syscall" : "={rax}"(ret)
                   : "{rax}"(n)
                   : "rcx", "r11", "memory"
                   : "volatile");
```
Это не говнораст - это ворованный из сишного компилятора инлайн-ассемблер. Ты опять обгадился.

>А теперь ты мне приведешь список реальных юзерспейсных программ, дергающих сисколлы напрямую?
Все, тупая ты обезьяна. Дёргать напрямую - это из родного рантайма, а не ворованного. Поэтому любой, кто пишет на С/С++ - дёргает их напрямую. Даже, насколько я помню, в го они дёргаются напрямую.
Твоя проблема не в том, что тебе говорят дёргать их через ворованный asm, твоя проблема в том, что ты украл чужой рантайм. Бери свой рантайм.
Почему это бездарное дерьмо не взяло это говнулибу, а украло libc? Правильно, потому что а) либоа говно, б) нужны не только сисколы.

Ответить | Правка | Наверх | 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

Похоже это ещё одна потуга жертвы пропаганды с соседней ветки. Для начала - цитирование определений сектантов не является каким-либо доказательством. Далее, выше уже показали libc, а значит никакого pure уже нет. Это ещё никто не считал количество unsafe + ffi в тоннах лефтпадов. А любое unsafe по определению не раст. Потому как это не более чем интероп с c-vm.
На расте нет ничего и ты этого никогда не покажешь. Даже компилятора и того нет. Даже рантайма и того нет. Даже аллокатора и того нет. Самых элементарных вещей нет.

Ответить | Правка | Наверх | 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-обработчиков н..." –1 +/–

Сообщение от 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 | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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-обработчиков н..."	+1 +/–
	Сообщение от Прорыв_запарты_фелиал (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-обработчиков н..."	+/–
	Сообщение от Аноним (64), 17-Июн-21, 02:12
	Я пиарил. Хотел на нём базу данных написать. Я руками его не трогал, но документацию и статьи внимательно прочитал. Стоит посмотреть GitHub Issues - сразу становится понятно что он не готов для чего-то серьёзного. Буду писать на Rust.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	156. "Представлена библиотека Aya для создания eBPF-обработчиков н..."	+/–
	Сообщение от Аноним (156), 30-Ноя-23, 23:02
	buh говорит что это не так. Это скорее Раст не готов в силу своей расплывчатости и бессистемности.
	Ответить \| Правка \| Наверх \| 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
	>А я не понимаю. Я даже не понимаю, что ты имеешь в виду под "моделью памяти". Что за модель памяти? Что-то типа RAM, EM, VAT[1]? Нет, наверное, это всё ж теоретические модели памяти _машины_, а не языка. Или что-то типа этого[2]? Не мог бы ты поделиться ссылкой, на тот теоретический фреймворк, в который позволяет тебе выстроить модель памяти раста? Что за нелепая херня? Идёшь и гуглишь memory model в контексте раста, можешь на гитхабе в ишьюсах поискать. Там спросишь сектантов что это такое. Нет, ни к какой машине модель памяти отношения не имеет. Это именно модель памяти языка, потому как язык где-то исполняется и у языка должны быть представления о том где. Под языком здесь понимается не то, что у языка есть какая-то память. Память есть у железяки. Понимаются именно представления языка о памяти. У говнораста, как и у любой скриптухи - нет какой-либо модели памяти. Говнораст существует только в рамках vm и его не заботит подобное. При этом даже по части скриптухи это не всегда так, в силучая когда скриптуха является первичной по отношению к вм, то вм считается частью языка. Допустим, поэтому если взять ту же жаву - модель памяти там жавы, хотя на самом деле jvm, потому как жава этим не занимается. А вот если взять какой-нибудь котлин, либо любую херню поверх jvm, то никакой котлин-модели-памяти не появится. Потому как скриптуха её делегирует vm, а вторичная скриптуха не определяет vm. Вот llvm это такая же vm, которая имеет свою модель памяти. Которая, в свою очередь, определяется сишной моделью памяти. Она куда более конкретна. В самом же говнорасте есть два языка. Это unsafe, который не более чем другой синтаксис для си. Там сишная модель памяти, многопоточности. Сишный же интероп и прочее. Если чуть более конкретней, то это обёртка над llvm-ir, вернее llvm-кодогеном. llvm даёт билдеры для функций, агрегатов, глобалов и прочего. Исключений. Того, что есть в си. Именно поэтому в гонорвасте более ничего нет. А сам же llvm-ir - это просто более формальная версия си. Потому как реализует его и его окружение в себе. Далее есть safe-говнораст. Это уже обёртка под unsafe, там совершенно левая модель памяти. Она в принципе памятью не занимается, а занимается ссылками. Поэтому моделью памяти её звать жирно, а зовётся так потому, что БЧ базируется именно на ней. Сам же БЧ - это максимально примитивное дерьмом. По-сути там есть единственный инвариант. mut ref == unique ref. Это все правила. Из них напрямую следует запрет шаринга. !mut ref == !unique ref, т.е. ридонли-шаринг. Ридонли-шаринг не считается за шаринг, потому как проблем не имеет. Там нет ни гонок ни прочей херне, о которой тебе рассказала пропаганда. unique ref так же не может быть шарингом. Шаринг предполагает не-уникальные ссылки. Далее unique ref == mut ref, только так в говнорасте может взяться мутабельная ссылка.
	Ответить \| Правка \| Наверх \| 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 +/–
	Сообщение от JackoNeill (?), 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
Новости 50 минут, а срача о ненужности раста на 300 сообщений нет. Opennet, выздоравливай.
Ответить \| Правка \| Наверх \| Cообщить модератору