Дэниел Алмейда (Daniel Almeida), занимающийся развитием видеокодеков в компании Collabora, представил для обсуждения разработчиками ядра Linux новую реализацию прослойки для использования аппаратных декодировщиков видео в формате VP9 в подсистеме V4L2, применяемой для организации доступа устройствам видеозахвата, таким как web-камеры и TV-тюнеры. Код прослойки полностью переписан на языке Rust и ориентирован на работу с драйверами rkvdec и hantro, предоставляющими доступ к аппаратным средствам ускорения декодирования видео, доступным в чипах Rockchip и Hantro...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60682
В общем направление развития понятно. Я все свои новые pet проекты буду писать на Rust. С Zig тоже перепишу.
А как же невозможность написать на Раст код, который изменяет память с разных потоков одновременно?
Помню ты мне рассказывал, что это не просто важно, а жизненно необходимо!
И что раст без такой функции вообще плохой язык.
> А как же невозможность написать на Раст код, который изменяет память с разных потоков одновременно?Вообще-то можно. Можно например создать тип `MyPtr` как обертку для указателя,
объявить что для этого типа реализован "Send", и можно будет
копировать указатель и разъименовывать в разных потоках,
но это конечно потребует использования "unsafe".
А еще лучше использовать готовые и проверенные примитивы - Arc/Mutex/Rwlock
Нельзя сделать просто, как в Zig. Будем делать "сложно", если понадобится)
На питон перепиши, не ошибёшься.
Или на джаваскрипт. Всё летать будет, отвечаю.
А если с привлечением фреймворка Electron, ваще реактивно будет.
Ты перепишешь. Нет это промежуточное направление. Хуанг сказал он стремится, чтобы программы писали программы, чтобы любой человек мог создавать программы через компьютер - программисты не нужны с написанием кода. В принципе отчасти так уже и делают берут готовое и стыкуют. А выйдет у них так сделать кто знает? Ответ мне не нужен.
Как я понял имеется ввиду что-то вроде разновидности GPT для создания готового кода под нужные задачи.
Это моё предположение понимание из его слов, там где я его слова сказанные увидел, он сказал одной фразой. Ещё могу предположить, что сложный код смогут создавать через аналог GPT только те у кого будут определённые дорогие мощности, а простое будет доступно в открытом доступе.
Это всё я. Могу обнадёжить немного, не всё так грустно, не в пустыне живём. Работа будет. Не выйдет устроится писать код так как GPT уже пишет не беда копать лопатой или трактором, вёдра с чем-то носить, канализацию чистить и тому подобное GPT научить делать не возможно. Если только заменить всех водителей всей строительной техники на автоматическое управление - возможно, с комбайнами так уже сделано, где водитель управляет комбайном, а где и сам комбайн программой управляется. КамАЗ тестирует фуры без водителей. В тестовом режиме ездят такие машины. Но! с сантехниками так не выйдет.
> Но! с сантехниками так не выйдет.Т.е походу ничего ен поменяется?
Опять придется или разгребать овна, или исправлять бракоделие, или делать бракоделие)
Даже фразу "ну прошлый мастер какой-то ужась сделал" менять не придется :-D
Всего один unsafe на 2к строк кода.
И тот в fn v4l2_vp9_seg_feat_enabled_rs, который нельзя сделать без него, потому что это FFI extern "C".
Неплохо, неплохо.
> потому что это FFI extern "C"Уточню, там unsafe не именно из-за FFI.
А потому что извне приходит feature_enabled, которая с точки зрения раста "неизвестно что и никаких гарантий на нее нет".
Поэтому вызов from_raw_parts_mut должен быть обернут в unsafe.
> с точки зрения раста "неизвестно что и никаких гарантий на нее нет".Почему эту точку зрения не пофиксят? 🤔😐😏
Иди и фикси
При добавлении rust в ядро говорили, что будут его использовать, в том случае, если даст какое-либо преимущество.Новая реализация дала преимущество?
Сколько раз встречается на 2000 строк слово unsafe,
PS:
Хотя сам отвечу. 1.
Хороший пример.
> Новая реализация дала преимущество?Да, там стало меньше потенциальных дыр в ответственном компоненте.
> Сколько раз встречается на 2000 строк слово unsafe
Один раз. В функции v4l2_vp9_seg_feat_enabled_rs (https://gitlab.collabora.com/dwlsalmeida/for-upstream/-/comm...)
Еще вопросы?
> Да, там стало меньше потенциальных дыр в ответственном компоненте.В 800 строках изолированного кода?
1200 строк - там данные забитые в исходники.
Как пример - хороший вариант. Показать преимущества - не получилось.
> Один раз.
Это я уже нашел.
какие дыры могут быть в разборе фреймов от железного декодера?
> какие дыры могут быть в разборе фреймов от железного декодера?О, не нужно недооценивать сишников!
Как будто есть мало месть где можно выйти за пределы буфера или записать не туда.
Аппеляция к неким теоретически возможным дырам всегда умиляет, не не убеждает.
> Хотя сам отвечу. 1.но в него обёрнуто половина кода
> но в него обёрнуто половина кодаРастохейтры настолько тупы, что не могут заглянуть в диф и увидеть что там одна строка.
Но еще больще впечатляют д###бы, которые их плюсуют.
там пофиг что там в коде, даже заглядывать в эту портянку из спецсимволов не охото
Ну так бы и сказал "длинные слова и спецсимволы расстраивают опилки в моей голове".
И я сразу бы понял - вот он эталонный неосилятор!
Который код не читал, но умный коммент нагадил.
>какое-либо преимущество."прослойка" должна давать преимущества?
да, один, но эта функция вызывается уже в десяти местах..
Раст уже настолько крут что может тягаться с ассемблером?
Зачем там ассемблер?
В переписывании указателей на структуры - c ассемблером мог бы потягаться gwbasic.
А больше ничего эта аж двухтысячестрочная прослойка к прокладке ничего и не делает, декодер - в железе.Нишка хруста вполне определилась.
А вот и кекспертное мнение из самых лучших совковых НИИ.
С учетом кучи проектов которые уже используют раст, то пук знатный, но в лужу.
Наверное про видео драйвера ты не слышал.
Но даже у него уровень аргументации выше, чем у тебя - какой-то поток мыслей обиженки на весь мир.
Переписали бы сломанный драйвер для амлоджиков, эти и так хорошо работали.
> Переписали бы сломанный драйвер для амлоджиков, эти и так хорошо работали.А как ты перепишешь то что уже сломано?
Его вначале исправить нужно, а потом переписывать.
Если там ошибки в логике обработки, то раст тебе не поможет - ты их точно также повторишь и на нем.
Считаешь, они могут только повторять...
Считаю что "они хотят повторять")
Если у тебя есть глючный инструмент, то логично сначала попробовать починиить или переделать его.
В случае с/с++ починить равноценно переделать)
Вот они и исправляют сначала то что им важно в данный момент. Заодно навыки растописания улучшают.
Если у тебя есть "глючный" инструмент(на самом деле нет), и ты хочешь его заменить(допустим) - зачем переделывать качественно получившуюся деталь, которая создана с помощью этого инструмента?
Так плохим инструментом хорошую деталь не сделаешь.
Деталь явно ущербная, вероятность ее поломки слишком большая - можно посмотреть новости про сишные дыры и это станет очевидно.Тут аналогия неправильная, лучше бы аноним со стройматериалом стравнил.
Можно строить дом из овна и палок.
И так строили в древности и некоторые ценители даже сейчас (саманный кирпич и глинобитные постройки).
Но прогресс не стоит на месте и сейчас строят из более удобных и в строительстве, и в обслуживании материалов.
Так же и с языками программирования.Каменный век закончился не потому что закончились камни.
А что-нибудь новое на расте пишут или только переписывают уже работающее?Так же хочу спросить у специалистов по поводу API. Раст умеет в ядре экспортировать свой API или только через сишные обёртки и соответственно через обмазывание unsafe?
> А что-нибудь новое на расте пишут или только переписывают уже работающее?Можешь пройтись по тегу, куча новых проектов пишутся.
из того что запомнилось мне
- ядро Maestro частично совместимое с Linux (www.opennet.ru/opennews/art.shtml?num=60391)
- Open Se Cura (www.opennet.ru/opennews/art.shtml?num=60071)
- Hickory DNS (www.opennet.ru/opennews/art.shtml?num=59883)
- Вирусы-червячки (www.opennet.ru/opennews/art.shtml?num=59473)
- криптолиба от амазона (www.opennet.ru/opennews/art.shtml?num=59004)Думаю сюда можно добавить и вариант ТОРа - тк его переписывает та же команда что и оригинал.
Но подход "давайте перепишем" с моей точки зрения более правильный.
У тебя уже есть готовый проект. Ты можешь использовать из него тесты, юзерфлоу, сравнивать/проверять корректность логики.
И заодно получить команду которая хорошо разбирается в новом языке.
Подход "давайте перепишем" - самый плохой из всех возможных и единственным оправданием для него может являться только "оно вообще не справляется с поставленной задачей, а исправить возможностей нет".Это азы программирования.
> "оно вообще не справляется с поставленной задачей, а исправить возможностей нет".Именно так.
Постоянные проблемы с памятью, одинаковые уже десятки лет - use-after-free, double-free и out-of-bounds.
И да, исправить возможности нет - тк исправить окаменевшие мозги сишников это не реально.А переписывание на новый ЯП - это полность изменение кода.
По хорошему остается только логика и то ее тоже можно улучшить с учетом возможностей языка.
Например выкинуть уродливые контрукции типа "нам достаточно и UINT, но будем использовать знаковый тип, чтобы отрицательными значениями пробрасывать ошибки ."
> самый плохой из всех возможныхЭто прекрасный вариант. Он позволяет заменять код частями, прогоняя тесты и отслеживая регрессии.
Автор так и пишет:
f) run the test suite (fluster.py run -d GStreamer-VP9-V4L2SL-Gst1.0 -ts VP9-TEST-VECTORS)
g) results should be the same both with and without this patch
> отслеживая регрессиину какие регрессии в расте, ну? Это ж раст с безопасной работой с памятью
А как гарантии безопасности памяти тебе помогут при копипасте? или сравнение перепутать?
> А что-нибудь новое на расте пишут или только переписывают уже работающее?Zed зарелизили намедни. Но пока только для iOS.
> Раст умеет в ядре экспортировать свой API или только через сишные обёртки и соответственно через обмазывание unsafe?
#[repr(C)] функции имеют C'шный ABI, их можно вызывать из C кода непосредственно.
Но, скорее всего, эти #[repr(C)] функции будут обёртками, чьей задачей будет решить в чём доверять C'шному коду, а в чём нет, посредством приведения типов.
Например, если в функцию передаются указатели, то они будут raw указателями, и rustc не может ничего гарантировать относительно них. Тебе придётся принять решение за rustc и сказать, что валидности этого указателя можно верить, и при помощи unsafe преобразовать его к &-указателю.
Плюс могут быть другие нюансы типа impedance mismatch. Например, rust'овые строки гарантированно валидный utf8, все строковые функции полагаются на это, и могут сегфолтнуть на невалидном utf8. То есть если ты хочешь работать со строкой полученной от C-кода как с &str, тебе придётся проверять на валидность utf8 или просто поверить в валидность и принять без проверки. Ещё с длиной придётся выкручиваться, считать её перед кастом. В ядре, я подозреваю, они используют не &str, а &CStr или что-нибудь своё доморощенное в этом стиле. Но даже в случае доморощенного типа-обёртки придётся принимать решение -- считать ли длину строки перед приведением типа, или работать со строкой в C'шном стиле, не зная её размера.
В общем, на стыке C и Rust придётся какие-то танцы с бубном выполнять, и там неизбежно полезут unsafe'ы, потому что rustc не может ничего предполагать о поведении C'шного кода. И вероятно придётся создавать обёртки, которые будут заниматься исключительно этим -- приведением типов, где-то выполняя дополнительные рантайм проверки, где-то просто волевым решением заявляя расту "этот указатель считать валидным".
https://youtu.be/CEznkXjYFb4?t=930
есть один крейт kernel, реализующий подсистемы через unsafe-обертки. весь слой выше - драйверы и прочее используют этот крейт и не имеют unsafe. в этом основной замысел.
> А что-нибудь новое на расте пишут или только переписывают уже работающее?А что, у тебя есть какие-то распространённые востребованные для решения задачи, под которые еще никто ничего раньше не написал?
А то ты любую задачу, если уже для её решения написали какой-то софт, называешь "переписывают работающее".
Так-то с таким подходом и ядро лулникса, и вэйланд и 100500 DE - это "переписывание уже работающего". И все шутеры после вульфенштайна 3Д (даже дум).
> А что, у тебя есть какие-то распространённые востребованные для решения задачи, под
> которые еще никто ничего раньше не написал?Если после переписывания функциональность не увеличилась или вообще уменьшилась, то это бесполезное переписывание.
> Если после переписывания функциональность не увеличилась или вообще уменьшилась, то это бесполезное переписывание.Ооо, теперь я вижу ЦА, которое живёт по плану: не буду ставить этот патч безопасности, ведь новой функциональности не добавилось.
Если пропадёт пачка всяких там выход за границы массива, UB и прочего CVE-генерирования под лозунгом "тут тоже можно безопасТно писать, просто ну не шмогла я, не шмогла" (говоря проше: повысилась безопасность) - то вполне.
Но никому в здравом уме не придет в голову переписать Doom 2016 и сделать из него Wolfenstein 3D, но на Расте, чем регулярно и занимаются переписывальщики.
>Rockchip и HantroТак это для ARM SoC. Там пусть экспериментируют.
Новость написана так, будто на расте написали декодер vp9. Хитро, хитро.На самом деле никакого декодера там в помине нет - обычный разбор уже готовых битовых полей, ничем не отличающийся, например, от разбора сетевых фреймов.
Не вижу ни одного преимущества, кроме синтаксического замусоривания красивого С-подобного кода с целью усложнить чтение кода.
Новость совершенно нормально написана. Ну если дальше заголовка читать, конечно. Хотя и он в заблуждение не вводит.
Ты не в состоянии понять заголовок "Код ПОДДЕРЖКИ кодека VP9"?
Потом про декодер ты придумываешь сам...
А потом идешь громко возмущаться в комменты!Может вначале стоит научиться читать? И желательно глазами.
>И желательно глазами.А может сам попробуешь для начала? "Поддержка" может означать и реализацию кодека.
> На самом деле никакого декодера там в помине нет - обычный разбор уже готовых битовых полейдык это и есть то, с чем идеально справляется нескучный йезычок.
Главное не давать ему перекладывать эти поля непосредственно в порты железяки - что в данном случае с блеском и сделано (правда, опять не хрустиками - но они точно выбрали объект приложения усилий)
> Не вижу ни одного преимущества
почему? Он действительно идеален для работы по переписыванию полей структурок. И защищает от механических ошибок. А от боровчекера в двух тысячах строк из которых 2/3 оказывается и вовсе не кодом - вполне можно и убежать.
Стоит ли оно таскания за собой еще одного отдельного громадного сборочного инструментария - ну так себе конечно вопрос.
>Он действительно идеален для работы по переписыванию полей структурок.видели недавно, как структуру из двух интов16 заменили на просто инт32, такое он может?
> с целью усложнить чтение кода.Так это же самое главное в современной айтишечке. Предел своих возможностей человечество уже достигло и теперь чтобы собирать бабло пошли по пути искусственного усложнения, преподнося хомячью это как "упрощение" и "улучшение".
К сожалению предел возможностей люди овстигли еще 30 лет назад, когда писаки на СИ так и не научились не портить память((
Но что самое страшное, им за это не надавали ко корявкам!
Представляю насколько сильнее это всё будет тормозить и насколько больше занимать памяти. Реально айтишечка свернула куда-то не туда.
Хм... посмотри сравнение С и Раста.
Например benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html
И ты увидешь что они идут примерно наровне.
Что говорит о твоих познаниях в теме)Так что айтишека свернула, а тебя оставила за бортом.
Такова плата за сложность
Есть статья на хабре, «Ржавая» IP-камера: прошивка на rust
Теперь рокчип будет еле шевелиться.
На Linux - да. Зато есть шанс для Free/NetBSD.
О, оказывается, Rust обладает скрытым свойством, работать быстрее в БЗДях!
Ага. По причине отсутствия присутствия.
Видимо, на расте совсем мало пишут, раз про 800 строка кода целую новость делают.
Чуть более года назад в 13-м андроиде было примерно 1.5 млн строк кода на расте. Но тебе ведь всё равно, ты ведь в комменты к новости зашел не за правдой, а сладкого хлебушка поесть и самому набросить на вентилятор.
А сколько на C и C++? Google заявил, что их цель - не переводить существующий код C/C++ на Rust, а скорее направить разработку нового кода на безопасные для памяти языки, не только Rust кстати.
VP9 устарел, мало где поддерживаеться. В отличии от H.264/HEVC/AV1
VP9 появился позже H.264. Это VP8 не видел, чтоб использовался.
Сейчас в Раст появилось движение снизить гарантии для упрощения написания код.
Учить язык сложно
https://www.tomshardware.com/software/security-software/whit...Капец для си-шников... ;)
Ну если NSA предлагает/намекает, то да, точно всё будет безопасТно.
Дядя Сэм конечно же плохого не посоветует. Но прошивку для F-35 пишут на C и C++.