Представлен первый выпуск библиотеки 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
И как у этого crate с thread safety?
Как обычно, надо полагать. Data race исключаются как класс, пока ты не прибегаешь к unsafe, а остальное всё в твоих руках. А почему ты спрашиваешь? Есть основания полагать, что у него ситуация с thread-safety отличается от дефолтной в расте?
> Как обычно, надо полагать. Data race исключаются как класс, пока ты не
> прибегаешь к unsafe, а остальное всё в твоих руках. А почему
> ты спрашиваешь? Есть основания полагать, что у него ситуация с thread-safety
> отличается от дефолтной в расте?Ну, я помню смешные курьёзы с errno, который в стандарте переменная, но для thread-safety сделано как макрос, разворачивающийся в вызов функции. Интересно, помнили ли об этом растовики, когда писали свой crate.
> Ну, я помню смешные курьёзы с errno, который в стандарте переменная, но
> для thread-safety сделано как макрос, разворачивающийся в вызов функции.Чё за курьёзы? Я не помню. Мне было бы интересно посмотреть, как кто-то не справился не заметить таких нюансов.
> Интересно, помнили
> ли об этом растовики, когда писали свой crate.А, ну это общая проблема создания safe API поверх unsafe операций. Тут она несколько осложняется тем, что там unsafe будет во все поля из-за интерфейса с внешним кодом, который rustc не может проанализировать на safety, и поэтому на всякий случай считает unsafe. То есть, в unsafe будет заворачиваться слишком много, и поэтому придётся проявлять чудеса умения обходить грабли.
Да, вероятность косяков повышена. Тут ты прав.
```
__thread int errno;
extern __thread int __libc_errno __attribute__ ((alias ("errno"))) attribute_hidden;
```
А вот и жертвы пропаганды нарисовались. Модель памяти раста не предполагает конкурентного доступа, а когда нет конкурентного доступа нет гонок. Тебя обманули. Меньше лозунгов ретранслируй и больше тему изучай.Представляешь, отличается. Раз раст не может в конкурентный доступ, то любое его наличие требует unsafe, хотя unsafe к расту не имеет никакого отношения, потому как имеет как минимум другую модель памяти, даже базовые примитивы иные. Потому как это просто обёртка поверх llvm-ir и сишного интеропа с llvm.
> А вот и жертвы пропаганды нарисовались. Модель памяти раста не предполагает конкурентного
> доступа, а когда нет конкурентного доступа нет гонок.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
>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
Зачем мне куда-то заглядывать, если я, в отличии от жертвы пропаганды, понимаю модель памяти используемую растом. И, очевидно, могу вывести из неё возможное и невозможное. Мне ненужна для этого табличка для дошколят с готовыми ответами.
Братишка, напиши про zig, а то чет его тут пеарят.
Я пиарил. Хотел на нём базу данных написать. Я руками его не трогал, но документацию и статьи внимательно прочитал.Стоит посмотреть GitHub Issues - сразу становится понятно что он не готов для чего-то серьёзного.
Буду писать на Rust.
buh говорит что это не так. Это скорее Раст не готов в силу своей расплывчатости и бессистемности.
>>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 доступом, но это не значит, что нельзя иметь глобальную хеш-табличку символов, где можно конкурентно эти символы искать и откуда их можно конкуретно тягать.
> И, очевидно, могу вывести из неё возможное
> и невозможное.Нет, из модели ты _по-определению_ модели не можешь вывести всего. Модель по-определению и по-построению рассматривает только некоторые свойства реальности, игнорируя все остальные. Из геометрии Евклида ты не выведешь общую теорию относительности с её пространством-временем. Хотя геометрия Евклида -- это модель пространства, в котором мы живём. Так и из модели памяти языка ты не сможешь вывести все возможные утверждения про язык. Более того, не все утверждения про язык, которые ты сможешь вывести будут применимы.
>А я не понимаю. Я даже не понимаю, что ты имеешь в виду под "моделью памяти". Что за модель памяти? Что-то типа 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, только так в говнорасте может взяться мутабельная ссылка.
> ... safety?Там где есть JIT безопасности нет!
прикольно бы еще напомнить что такое (e)bpf
> прикольно бы еще напомнить что такое (e)bpfExtended BlackArch Packet Filter
Хотя некоторые утверждают, что придумано оно было еще в доситорические времена в Blue Linux.
>> прикольно бы еще напомнить что такое (e)bpf
> Extended BlackArch Packet Filterне BlackArch, а Berkley
По-моему, там ирония. Но это не точно.
>>> прикольно бы еще напомнить что такое (e)bpf
>> Extended BlackArch Packet Filter
> не BlackArch, а BerkleyBerkeley Linux? Никогда о таком не слышал.
Это предыдущая версия до redhat enterprise bsd
> Это предыдущая версия до 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
>
Очередной костыль, если вам так будет понятнее
Что бы там луддиты не говорили, а всё-таки за Хрустом будущее.
Ага за джаваскриптом, луддит.
Спасибо, поржал. Продолжайте снабжать нас веселыми историями.
Самое страшное то, что весьма вероятно, смеяться то он будет как раз последним.
Девушки рыдают, матросы смеются, как говорится.
"А Таня была в каске и только засмеялась" (с)
Все равно потечет и будет небезопасной зачем тут раст то?
Новости 50 минут, а срача о ненужности раста на 300 сообщений нет. Opennet, выздоравливай.
видимо уже начинается стадия принятия
А потом окажется, что все те "стадии" - навязанная чепуха( что-то типа "если есть из маленькой тарелки то наешься быстрее и меньшим количеством еды!!111" )Или, к слову о том, что, если ребенку сделать/сказать что-то что его огорчит, он сразу или расстроится или сразу же полезет в драку
>видимо уже начинается стадия принятиявидимо уже начинается стадия наплеватия *очевидный фикс*
После стадии отторжения не может начаться стадия принятия. Кому надо было уже ржавчины хлебнули и свои выводы сделали.
Просто ненужность раста такова, что даже срач о его ненужности не нужен!
>апи ещё не стабилизированДля раста это нормально.
Да и "пока" там можно смело убирать.
Мляяя... jit в ядре, из под обычного пользователя, версия 2 - powered by rust. Дедушка Столлман, срочно, пили гпл4, проприерасты прорвались.
Причём тут проприетарщина и GPL? У тебя каша в голове.
Кто бы сомневался что всё равно без libc ничего не могут. Хипстеры такие хипстеры.
Хотел было спросить, зачем тамpub unsafe extern "C" fn malloc(size: size_t) -> *mut c_void
но нашёл вот это:
pub unsafe extern "C" fn strlen(cs: *const c_char) -> size_t
> но нашёл вот это:
> 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 набором чаров)
>> но нашёл вот это:
>> 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 набором чаров)Если убрать малознакомые мне слова и попытки манипулировать, то правильно ли я понимаю, что тут написано о невозможности обработать массив октетов средствами Раста? (но этого не может быть).
>>> без 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 синдрома)?
>[оверквотинг удален]
>> то правильно ли я понимаю, что тут написано о невозможности обработать массив октетов средствами Раста?
>> (но этого не может быть).
> Тут написано о том, что строки в расте "совсем другие".
> А теперь глянь в реализацию strlen той же glibc
> https://github.com/lattera/glibc/blob/master/sysdeps/x86_64/...
> https://github.com/lattera/glibc/blob/master/sysdeps/arm/str...
> - предлагаешь велосипедить достаточно быструю (то есть использующую SIMD, выравненное
> чтение и прочее) для _внешнего_ типа данных чисто из "любви к
> исскуству" (ну и чтобы комментаторы на опеннете могли всласть покомментировать по
> поводу NIH синдрома)?Предлагаю перечитать сообщение, на которое Вы отвечали. Там был задан вопрос на эту тему. Если не понятно, что такое Бойер-Мур, поищите в сети. Если Вы не готовы дать ответ не мой вопрос, не тратьте время.
>> но нашёл вот это:
>> pub unsafe extern "C" fn strlen(cs: *const c_char) -> size_t
>> что бы я спросил: а зачем?
> Предлагаю перечитать сообщение, на которое Вы отвечали. Там был задан вопрос на
> эту тему. Если не понятно, что такое Бойер-Мур, поищите в сети.
> Если Вы не готовы дать ответ не мой вопрос, не тратьте
> время.Предлагаю перестать читать жопой и юлить и ответить наконец на вопрос: на*ера обязательно нужно велосипедить свою реализацию операции над _чужим_ типом данных? Что бы что?
То есть я сам должен ответить свой на вопрос, зачем Rust strlen()? Не проблема, напишу теперь уже без намёков: strlen() в Rust не нужна.Теперь ты расскажи, зачем ты тут нарисовался?
strlen действительно могли бы реализовать сами, но может быть, нужен и конкретно текущей libc. А без malloc нельзя было бы работать с теми кривыми сишными поделиями, которым подай аллоцированное, а освободят они сами естественно сишным free
> strlen действительно могли бы реализовать сами, но может быть, нужен
> и конкретно текущей libc.Зачем? Вызов внешней функции существенно дороже, чем встроенный (inline) подсчёт.
> А без malloc нельзя было бы работать
> с теми кривыми сишными поделиями, которым подай аллоцированное, а освободят они
> сами естественно сишным freeНе согласен с формулировкой. Можно. Да, для этого придётся переписать malloc на Rust и следить за изменениями эталонной реализации. Либо перехватывать вызовы free(). Это решаемая задача, но в данном случае трудозатраты вряд ли оправданы, как в случае со strlen().
как вариант это просто автогенерированный код
> как вариант это просто автогенерированный кодСпасибо. Это разумный вариант.
И очень сильно и сложно приседать, чтобы ничего не ломалось при LD_PRELOAD, скажем, jemalloc, по сути вызывая написанный на расте код через FFI.
И это уже в одном шаге от переписывания libc на раст. Что на самом деле идея красивая но неосуществимая, ведь glibc ужасает не только качеством но и объемом кода
> И очень сильно и сложно приседать, чтобы ничего не ломалось при LD_PRELOAD,
> скажем, jemalloc, по сути вызывая написанный на расте код через FFI.Это не эквивалентно "нельзя".
> И это уже в одном шаге от переписывания libc на раст. Что
> на самом деле идея красивая но неосуществимая, ведь glibc ужасает не
> только качеством но и объемом кодаНо Си ведь небезопасный язык. Значит libc небезопасна. Следовало переписать сначала её, а потом уже всё остальное.
> Кто бы сомневался что всё равно без 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).Кто бы сомневался, что жопоскриптозники в вопросе разбираются как козы в апельсинах?
Поскольку разбираетесь, подскажите, пожалуйста, вокруг какого syscall является обёрткой функцияpub unsafe extern "C" fn strlen(cs: *const c_char) -> size_t
> Поскольку разбираетесь, подскажите, пожалуйста, вокруг какого 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"?
Ещё одна жертва пропаганды. Сообщаю новость - сисколы и ядро никакой жопой не зависят от libc - её там в принципе нет. И libc - это не "platforms’ system libraries", потому как таких вообще не существует. Это "системные библиотеки" си, а не просто системные библиотеки. Да и само это понятие нелепо.
> Ещё одна жертва пропаганды. Сообщаю новость - сисколы и ядро никакой жопой
> не зависят от libc - её там в принципе нет. И libc - это не "platforms’ system libraries", потому как таких вообще
> не существует. Это "системные библиотеки" си, а не просто системные библиотеки.
> Да и само это понятие нелепо.Еще одна жертва чтения жопой, домысливания и гордого опровергания своих же домыслов.
Набор готовых сборок ржавой библиотеки для разных версий "stable API is nonsense" и *BSD ты что ли мейнтейнить будешь?
И точно-точно не будешь ныть на опеннете "Фи! Оно для чтения stdin хочет впендюрить свой рантайм вместо использования системного!"?
Жертва пропаганды поплыла. Тебе сообщили, что libc ненужна ни для сисколов ни для ядра. Это не говоря о том, что в переносимую либц, о который ты попытался закукарекать, сисколы в принципе не входят.Ну и да, типичная методичка обгадившегося трепла вида "да ты будешь" - показывай где буду. Бегом.
В результате что я вижу? Блеял про сисколоы - обгадился с сисколами. начал нести какую-то херню. Это не говоря о том, что libc в принципе ненужна ни для интеропа с си ни для чего угодно. libc в этой скриптухе существует только по одной причине - скрипуха бездарная не может в системщину. Поэтому приходится весь рантайм воровать. Начиная от юзерспейс-рантайм заканчивая компилятором. В школу, позорище.
> Жертва пропаганды поплыла. Тебе сообщили, что libc ненужна ни для сисколов ни
> для ядра. Это не говоря о том, что в переносимую либц,
> о который ты попытался закукарекать, сисколы в принципе не входят.Ты опять читал жопой? Или собрался заимодействовать с ядром и ebpf без сисколов - через либастрал?
> Ну и да, типичная методичка обгадившегося трепла вида "да ты будешь" -
> показывай где буду. Бегом.
> В результате что я вижу? Блеял про сисколоы - обгадился с сисколами.
> начал нести какую-то херню.Прочитал жопой, написаль хрень, опять прочитал жопой, опять написал хрень ...
> Это не говоря о том, что libc
> в принципе ненужна ни для интеропа с си ни для чего
> угодно. libc в этой скриптухе существует только по одной причине -
> скрипуха бездарная не может в системщину. Поэтому приходится весь рантайм воровать.
> Начиная от юзерспейс-рантайм заканчивая компилятором. В школу, позорище.Какие бурные фантазии очередного жопочтеца ...
> libc в этой скриптухе существует только по одной причине -
> скрипуха бездарная не может в системщину. Поэтому приходится весь рантайм воровать.
> Начиная от юзерспейс-рантаймНачинаю подозревать, что это правда. Стандартную библиотеку С++ (которому Rust якобы замена) возможно реализовать на С++ (+ вызовы ядра) а libc сделать вокруг неё обёрткой.
> заканчивая компилятором.
Всё же компилятор это не столь простая часть, как системная библиотека. Разумно использовать готовый для экономии времени и потенциальной поддержки новых архитектур.
>Начинаю подозревать, что это правда. Стандартную библиотеку С++ (которому Rust якобы замена) возможно реализовать на С++ (+ вызовы ядра) а libc сделать вокруг неё обёрткой.C++ является си, поэтому здесь нет никаких проблем. Проблема не в том, что какая-то скриптуха берёт что-то у си. Проблема в том, что эта помойная скриптуха декларирует свою самодостаточность и в принципе ортогональность с си.
>Всё же компилятор это не столь простая часть, как системная библиотека. Разумно использовать готовый для экономии времени и потенциальной поддержки новых архитектур.
Нет, это подход дерьма. У всех адекватных языков есть свой компилятор. Это основа любого языка. И компилятора у скриптухи этой позорной нет не потому, чтобы что-то упростить - это сказки для бедных. А потому что языка в принципе нет.
Вот выше там сектанты помойные спорили со мною на эту тему. Ты просто иди и посмотрим что в си есть, чтобы быть языком. Это и модель памяти и модель многопоточность и модель исполнения. Ничего этого в этой позорной скриптухе нет и никогда не будет. И именно это, в первую очередь, эти бездарности воруют, а не какие-то "новые архитектуры". Тебя просто обманули.
Полноценный язык должен являться первичным. Очевидно, что очень просто оттрансировать своё дерьмо в си, ведь ненужно ни о чём думать. А ещё лучше когда уже есть готовый кодогенратор в си(llvm и есть тот самый кодогенератор. Т.е. этот бездарный огрызок сам даже ir не генерирует).Но в чём проблема? Проблема в том, что ты становишься заложником чужой воли. Ты будешь исполнятся так, как нужно не тебе. И если ты захочешь пойти против - не сможешь. Вот си первичен по отношению к ллвм, ллвм сделан сишниками и так, как нужно сям.
Предположим, что если завтра в си введут изменения, которые потребуют изменения в llvm такого, что это поломает говнораст - всем будет похрен на говнораст.
Не вижу проблем с трансляцией в Си, когда речь идёт о каком-нибудь Vala. Более того, я не знаю, зачем там свой компилятор. Но там авторы честно обозначили, что они сделали некий продвинутый препроцессор для упрощения формошлёпства, а не очередного убийцу Си.
Я не говорил, что трансляция в си проблема. Она проблема тогда, когда ты сектант, который делает не-си с трансляцией в си.
Бороться с Си, транслируя в Си -- это не секта, а когнитивный диссонанс :)
>> Поскольку разбираетесь, подскажите, пожалуйста, вокруг какого 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"?Пока приходится ныть об уровне аргументации и качестве риторики.
> Раз не подскажете номер вызова, значит strlen() не имеет отношения к обёртке,
> как и попытка передёрнуть -- смысла.Твоя попытка передерга - тоже. Ну или ты можешь показать, где в сабже используется strlen?
>> всё равно без libc ничего не могут. Хипстеры такие хипстеры.
> Пока приходится ныть об уровне аргументации и качестве риторики.О да.
>> Раз не подскажете номер вызова, значит strlen() не имеет отношения к обёртке,
>> как и попытка передёрнуть -- смысла.
> Твоя попытка передерга - тоже. Ну или ты можешь показать, где в
> сабже используется strlen?Могу назвать вопрос унылой демагогией. Бремя доказательства, что strlen() является "System call ... wrapper function", лежит на заявителе.
> Могу назвать вопрос унылой демагогией.В смысле, вставить от балды не используемый сабжем "strlen" и требовать доказать что это "wrapper functions in glib" - демагогия? Согласен.
> Бремя доказательства, что strlen() является "System
> call ... wrapper function", лежит на заявителе.Бремя доказательства "всё равно без libc ничего не могут"? Несомненно!
>Бремя доказательства "всё равно без libc ничего не могут"? Несомненно!Срочно в школу, клоун. Не могут не требует доказательств. Как и "не существует". Ты настолько бездарность, что даже правильно методичку использовать не может.
Бремя доказательств не работает так, как ты блеешь. Оно касается не того, кто заявляет, а того, кто что-то заявляет. Утверждающий это не тот, кто выдвигает тезис, а тот кто выдвигает тезис утверждающий существование чего-то.
translate.google.com <- "generally"Это в тему коз и апельсинов.
> translate.google.com <- "generally"
> Это в тему коз и апельсинов.Так ты коза, дергаящая в своих программах сисколы напрямую?
Или очередной опеннетный апельсин-теоретик, который любит поныть (в зависимости от темы) "Пачему оно тянет еще один жирный рантай, не используя системное!© Зачем переписали?" и "А-а-а! Используют системное! Не осилили свое! Фууу!"?
А что, из Rust нельзя дёрнуть сискол напрямую? Скажите, Вас кто-то нанял, что бы Вы сливали столь популярный и многообещающий язык, или оно само так получается?
> А что, из 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
}
А теперь ты мне приведешь список реальных юзерспейсных программ, дергающих сисколлы напрямую?
> Скажите, Вас кто-то нанял, что бы Вы сливали столь популярный и многообещающий язык, или оно само так получается?Классика впопеннетных борцунов "противорастового сопративления" - когда нечего возразить по теме, пиши глупости про "слив" ...
>Логика уровня "А что, из С++ нельзя дернуть сискол напрямую или почему так никто не делает?!"Жертва пропаганды, С++ итак дёргает сисколы напрямую.
```
asm!("syscall" : "={rax}"(ret)
: "{rax}"(n)
: "rcx", "r11", "memory"
: "volatile");```
Это не говнораст - это ворованный из сишного компилятора инлайн-ассемблер. Ты опять обгадился.
>А теперь ты мне приведешь список реальных юзерспейсных программ, дергающих сисколлы напрямую?Все, тупая ты обезьяна. Дёргать напрямую - это из родного рантайма, а не ворованного. Поэтому любой, кто пишет на С/С++ - дёргает их напрямую. Даже, насколько я помню, в го они дёргаются напрямую.
Твоя проблема не в том, что тебе говорят дёргать их через ворованный asm, твоя проблема в том, что ты украл чужой рантайм. Бери свой рантайм.
Почему это бездарное дерьмо не взяло это говнулибу, а украло libc? Правильно, потому что а) либоа говно, б) нужны не только сисколы.
> А теперь ты мне приведешь список реальных юзерспейсных программ, дергающих сисколлы напрямую?Нет, не приведу. Знаешь, почему? Потому что у меня такая программа есть, я её сам написал. А если тебе что-то нужно, ты сам и ищи, хамам и балаболам я не помогаю.
>> А теперь ты мне приведешь список реальных юзерспейсных программ, дергающих сисколлы напрямую?
> Нет, не приведу. А если тебе нужны пруфцы моей точки зрения, то сам и ищи ...Ничего страшного - чего-то помимо унылой клоунады с демагогией от очередного впопеннетного борцуна с растом я и не ожидал.
Зато могу тебе рассказать, почему ты коверкаешь название сайта, на котором имеешь неосторожность при людях какать: потому что ты тут систематически какаешь. Проекция зафиксировалась в стойкую асссоциацию.
> Aya не использует libbpf и компилятор bcc,Начали за здравие...
> а предлагает собственную реализацию, написанную на Rust
... у которого под капотом тот же llvm, что и у bcc. Закончили за упокой.
> компилятор bcc,
>> llvm-bpf backend
> Начали за здравие...Очередной опеннетный комментатор начал за здравие
>> а предлагает собственную реализацию, написанную на Rust
>> pure Rust implementation
> ... у которого под капотом тот же llvm, что и у bcc. Закончили за упокой.А кончил посадкой в лужу ...
Похоже это ещё одна потуга жертвы пропаганды с соседней ветки. Для начала - цитирование определений сектантов не является каким-либо доказательством. Далее, выше уже показали libc, а значит никакого pure уже нет. Это ещё никто не считал количество unsafe + ffi в тоннах лефтпадов. А любое unsafe по определению не раст. Потому как это не более чем интероп с c-vm.На расте нет ничего и ты этого никогда не покажешь. Даже компилятора и того нет. Даже рантайма и того нет. Даже аллокатора и того нет. Самых элементарных вещей нет.
Очередное никому ненужное, недоделанное и глючное поделье на rust
Ненужное онаниму с Опеннета и, конечно же, им лично не протестированное, что позволяет ему смело испражняться в комментах с умным видом. Ведь, если тебе поставили плюсики, ты автоматически прав.
> Ведь, если сам себе поставил плюсики, ты автоматически прав.Пофиксил.
Поставил тебе плюсик, но после твоих слов никто не поверит, что это сделал не ты сам. То есть, я только что дискредитировал тебя как союзника в дебатах just for fun. Хотя, кто знает - может, это был не ты, а тот, первый Аноним, который специально хотел, чтобы все подумали, будто он сам себе их поставил, чтобы дискредитировать идею своего первого комментария. Многоходовочка, получается.
Каждый раз после прочтения комментариев анонимных экспертов с opennet начинаю ненавидеть rust всей душой. Понимаю что комментарии глупейшие, но всё равно читаю :-(
А я - любить. Столько лулзов еще ни один язык не доставлял.Писать на нем, само собой, я не планирую (мне моя психика дороже), но наслаждаться подгорающими жепками анонимов с обеих сторон баррикад - бесценно.
писать на сишарпе, там тоже есть ансейф.
Linux поддерживает 15 архитектур и что-то около сотни микроархитектур.Компилятор Rust поддерживает что-то около 9 архитектур.
Добавление Rust в ядро сократит число поддерживаемых линуксом архитектур.
На нем планируют писать драйверы. Драйвер и так практически всегда прибиты к одной или двум архитектурам. Так что ничего не сломается на неподдерживаемых. Потому что оно на них и не работало))
> "Представлена библиотека Aya для создания eBPF-обработчиков
> На нем планируют писать драйверы.Ты бы читал тему, прежде чем комментировать, а то складывается впечатление, что ты читаешь набор ключевых слов и отвечаешь исходя из их наличия.
это типа намек на то, что ebpf обработчики на расте не будут работать на платформах, не поддерживаемх им? с чего бы это? ebpf это виртуальная машина, берешь и собираешь свои обработчики на нужном железе под эту виртуальную машину, запускаешь на всех железках
> ebpf это виртуальная машинаНет. Почитай внимательней
> позволяющей создавать на языке Rust обработчики eBPF, запускаемые внутри ядра Linux в специальной виртуальной машине с JITпрочитал
>> позволяющей создавать на языке Rust обработчики eBPF, запускаемые внутри ядра Linux в специальной виртуальной машине с JIT
> прочиталТеперь прочитай что такое JIT и типы виртуализации
Прочитал и мнение не поменял. Давай короче, с пруфами, раз такой умный
Автор камента реально похоже не понимает что такое JIT:)Виртуальная машина всегда остается, просто интерпретатор этой виртуальной машины более не читает байт код, а читает лишь код собранный JIT. Но виртуальная машина с ее иерархией памяти, архитектурой все остается))
Я не понимаю, что такое JIT. Но кое-что слышал про just-in-time compiler. Он таки компилирует байт-код (то, что исполняется виртуальным процессором/машиной -- это такой большой switch/case, а не QEMU) в машинный (исполняемый непосредственно физическим процессором). Другое дело, что в некоторых реализациях компилируется не весь байт-код, а только часто вызываемый ветки -- тогда вирт.машина остаётся (она и решает, что требуется откомпилировать).
Это же не выпиливание имеющихся компиляторов и замена на этот. На неподдерживаемых платформах просто не будешь писать обработчики на расте, а будешь по-старинке. И уже написанные тоже никуда не исчезнут.
Т.о. те кто хочет писать на расте получат эту возможность, а те кто не хочет - даже не заметят.
> Т.о. те кто хочет писать на расте получат эту возможностьПока ещё не получат. До получат там пилить и пилить. К тому времени оно и здохнуть может.
Вообще немного больше чем 9. Подробнее можно почитать тут https://doc.rust-lang.org/nightly/rustc/platform-support.html
Плюс - а какие из недостающих восьми реально где-то используются, а не являются окаменевшим говном мамонтов которое тащут только из-за пары корпораций?
> Вообще немного больше чем 9. Подробнее можно почитать тут https://doc.rust-lang.org/nightly/rustc/platform-support.html
> Плюс - а какие из недостающих восьми реально где-то используются, а не
> являются окаменевшим говном мамонтов которое тащут только из-за пары корпораций?В любом случае, добавление Rust в ядро сокращает количество поддерживаемых архитектур. А это не есть карашо.
Странная логика.
Linux 5.10 LTS дропнул поддержку больше десятка платформ (подробнее тут https://www.phoronix.com/scan.php?page=news_item&px=2021-Lin...) и еще больше собираются дропнуть.
Это тоже "не есть карашо"? Или это "это другое"?
> Это тоже "не есть карашо"? Или это "это другое"?Да. А почему странная?
>Плюс - а какие из недостающих восьми реально где-то используются, а не являются окаменевшим говном мамонтов которое тащут только из-за пары корпораций?Предлагаю поддерживать только wintel, всё остальное маргинально.
Ну зачем себя так ограничивать - там есть еще ARM, MIPS, RISC-V и куча других.
Любители старенького могут выбрать PPC или S390x. Так что есть из чего выбирать!А какой-то M32R который дропнули даже в линуксе никто нафиг не сдался. И там есть еще куча аналогичных архитектур, которые только формально поддерживаются.
Это выведет ядро Линуха на новый уровень навороченности и замороченности.
И зависимости от кого надо
Хорошо, наверное, что начали появляться готовые проекты на расте...
>готовые проекты на расте
>
>API ещё не стабилизированТонко! И в этом вся суть "готовых" растовых проектов.
А что вообще есть у нас готового, что не будет доработано или исправлено?
К сожалению или к счатью не мне нудить. Но нет, не готовые. Сырое оно как гавно мамонта.
Всем радетелям за новое безопасное рекомендую уточнитт, кто владеет crates.io - сюрприз гарантирую
Rust Fondation?
> Всем радетелям за новое безопасное рекомендую уточнитт, кто владеет crates.io - сюрприз гарантируюТо ли дело Владетель kernel.org, да?
> Registrant Organization: The Linux Foundationhttps://www.linuxfoundation.org/about/board/
MICROSOFT
ORACLE
AT&T
IBM
HUAWEI
INTEL
Или как обычно, "это другое!"?
Единственный плюс раста это уродливый и упоротый цэпэпэ который от стандарта в стандарт становится размером с глобус и при этом тянет с собой сишные костыли и подпорки... это жк наверное случится и растом если он когда нибудь взлетит, но потом...В любом случае по уродливости и упоротости синтаксиса раст занимает почетное второе место сразу за крестами
Почему нельзя было пилить синтаксис раста с оглядкой не на наркоманский CPP, а на более адекватный C# ну или Java на худой конец? И я не говорю о реализации языка, а о синтаксисе! Синтаксис можно было человеческий сделать?
Здешнее нытьё про синтаксис уже начинает утомлять. Без семантики синтаксис не имеет смысла, вот и учите её - тогда придёт навык чтения, и все проблемы отпадут. Такое ощущение, будто половина опеннетчиков остановилась в профессиональном развитии и категорически не приемлет изменений в привычном порядке вещей. И с какой стати он вдруг стал похож на C++? Это, скорее, ML в сишной обёртке, со своей спецификой. Если тебе нужен синтаксис, как в C# или Java, то и пиши тогда на них, и забей на Rust. Новые ЯП появляются не для того, чтобы делать всё по-старому. Новая семантика - новый синтаксис.TL;DR
Синтаксис уже человеческий, просто некоторым человекам лень перестраивать мышление.
Синтаксис жуть криповая, это тебе любой скажет покажи ты ему код на расте... даже в крестах если не юзать в нем сишную хрень типа указателей, си-строк, макросов выглядит на порядок лучше и читабельней
Ну, если для тебя код на С++ читабельнее, то я рад, что не являюсь твоим коллегой. И, кстати, "выглядит лучше" и "читабельнее" - синонимы. Как по мне, незамеченная тобой тавтология - признак того, что ты пытаешься в этом убедить не только меня, но и себя. Впрочем, я не исключаю возможности в один прекрасный день увидеть плюсовой код, который я счёл бы читабельным. Жаль только, что плюсовики всё никак не договорятся о стиле кода, а и без того раздутый стандарт языка только разрастается с каждой итерацией, заставляя задействовать все доступные ресурсы мозга при чтении любого мало-мальски нетривиального кода, чтобы не упустить мелкие, но очень важные детали самой запутанной семантики, которую только можно найти в мире ЯП.
Читать научись... если тебе попадался C++ на макросах и указателях на указатели то это не плюсы, это си стайл
Реально так
Ответ есть в этой статье: https://habr.com/ru/post/532660/