Дэниел Алмейда (Daniel Almeida), занимающийся развитием видеокодеков в компании Collabora, опубликовал в списке рассылки разработчиков Linux-ядра начальную реализацию драйвера Tyr для GPU ARM Mali, в которых применяется технология CSF (Сommand Stream Frontend), таких как Mali G310, G510 и G710. Код драйвера написан на языке Rust и насчитывает чуть больше 600 строк кода. Работа над драйвером Tyr ведётся совместно сотрудниками компаний Collabora, Arm и Google...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63490
600 строк кода, а шуму то...
Это 600 строк правильного кода, а не всякого там не правильного
unsafe на месте
> unsafe на местеЦелых три ансефа на все изменения.
lore.kernel.org/dri-devel/20250627-tyr-v1-1-cb5f4c6ced46@collabora.com/Ну и понятно почему
// This type is the same type exposed by Panthor's uAPI. As it's declared as
// #repr(C), we can be sure that the layout is the same.Это же понятно, что везде, где придется взаимодействовать с богомерзкой, придется добавлять unsafe
> Целых три ансефа на все изменения.Либы посчитай. Не-unsafe кода там в принципе нет.
А так, одного достаточно, чтобы поломать сказки про гарантии. Поэтому не переживай.
А с учётом этого(https://github.com/Speykious/cve-rs) не-unsafe даже в мечтах не возможен.
> А с учётом этого(https://github.com/Speykious/cve-rs) не-unsafe даже в мечтах не возможен.Уже давно исправлено, смени методичку.
github.com/Speykious/cve-rs/issues/3
Не исправлено. Этого нет в языке, а заявляется безопасность языка, а не левой поделки. С таким же успехом в си нет уб. Да и где угодно нет.
https://doc.rust-lang.org/cargo/commands/cargo-miri.html
https://github.com/rust-lang/miri
> move of the Miri engine into the compiler finally came to completion in early 2018....
> Этого нет в языке, а заявляется безопасность языка, а не левой поделки.
> левой поделкиКекспертиза изо всех щелей ...
> Этого нет в языке, а заявляется безопасность языка
> into the compilerКекспертиза изо всех щелей ...
>> Этого нет в языке, а заявляется безопасность языка
>> into the compiler
> Кекспертиза изо всех щелей ...Кекспертушка, ты же осознаешь, что на самом деле -- ссылался на баг в компиляторе? Потому что в "языке", внезапно, "оно" есть.
> So far, all our bugs are implemented using a single soundness hole in the Rust compiler.
> The explanation is detailed in the lifetime_expansion module.Или ты по своей же ссылке (как обычно) - дальше заголовка не читал?
https://github.com/Speykious/cve-rs/blob/main/src/lifetime_e...
# How it works
//!
//! There is a soundness hole in the Rust compiler that allows our domain expansion to work.
//!
//! In the [`expand`] function, we use [`lifetime_translator`] with [`STATIC_UNIT`],
//! which has a `'static` lifetime, allowing us to translate an arbitrary lifetime
//! into any other lifetime.
//!
//! `rustc` *should* infer that one of the lifetimes does not outlive `'static`, so
//! that we can't use [`lifetime_translator`]; however, for whatever reason, it doesn't,
//! so this exploit works.
//!
И вот так, с вами, кекспертами - каждый раз.
> Кекспертушка, ты же осознаешь, что на самом деле -- ссылался на баг в компиляторе?
> заявляется безопасность языкаЗдесь у агитатора явно проблемы с тем, чтобы отличить язык и компилятор языка.
> Потому что в "языке", внезапно, "оно" есть.
Нет. Никакой безопасности в языке нет.
> in the Rust compiler
Здесь агитатор также не смог отличить тезис и пример проявления этого тезиса.
> И вот так, с вами, кекспертами - каждый раз.
О том, что анализатор(на самом деле просто поделка с названием посолиднее) воткнутый в "компилятор"(которого у руста нет) не становится ни языком, ни даже частью компилятора, агитатор узнает в следующей серии.
>>(Автор(ы) cve-rs) So far, all our bugs are implemented using a single soundness hole in the Rust compiler.
> (опеннетный кексперт) Здесь агитатор также не смог отличить тезис и пример проявления этого тезиса.Не, ну опеннетному кексперту-то всяко видней, что там и как на самом деле, ага ...
Да, маня, мне виднее что я имел ввиду на самом деле в своём посте. И свидетельства тому выше.Кстати, тут агитатор совсем запутался в показаниях. Если котируется мнение только авторов чего-либо(не комментов на опеннете), зачем агитатор пытается в _коментах на опеннете_ рассказывать что и как на самом деле? Является ли он автором чего-либо? Нет. Вменяем ли он? Нет.
Ну и что-то он слишком быстро слился со своего тейка "интегрировано в компилятор - значит часть компилятора". Наверное я его спугнул всё-таки и он почуял неладное.
> Ну и что-то он слишком быстро слился со своего тейка "интегрировано в
> компилятор - значит часть компилятора".Это буквально часть компилятора, все comptime вычисления через miri идут)
А всё остальное я постом ниже описал нормально
Нет, не часть. Никаких "comptime вычислений" в расте нет. Как впрочем и компилятора, но то ладно.Кстати, как интересно агитатор запутался в показаниях. Если все "вычисления"(допустим, они есть) идут через мири, то что было до мири(18 год, кажется)? Агитка про безопасность уже была и не первый год. Безопасности не было? Да нет, лозунги были всё те же. То есть ничего не поменялось.
> А всё остальное я постом ниже описал нормально
Там классическая агитка "ну когда-нибудь поправят - не считается"/"а вот баг же заведён - значит не дыра". Помимо полной несостоятельности этих тезисов, тут ещё и ссылки на себя. Это примерно как "в сишке нет уб, ведь его наличие признаётся/в стандарте есть - значит это просто баг реализации/стандарта, не считается".
> Да, маня, мне виднее что я имел ввиду на самом деле в своём посте. И свидетельства тому выше.Твои унылые переобувания в прыжке, ты хотел сказать? Сколько их тут уже было, 3 или 4?
> Кстати, тут агитатор совсем запутался в показаниях. Если котируется мнение только авторов
> чего-либо(не комментов на опеннете), зачем агитатор пытаетсяБалаболка, ты ж сам - на них ссылся, в качестве "доказательства" своего "тезиса".
Получается обычное опеннетное "тут читаем, а там рыбу заворачивали, вот!".У тебя ж вся цепочка "аргументации" построена на повторении на разные лады "в ЯП того-этого нет, потому что в компиляторе есть баг и его можно использовать".
Божественный (нет) уровень, че.Кстати, агитатор чего и почему? Ткнуть опеннетного кексперта носом в л(а/o)жу - уже стало "агитацей за раст"?
> Ну и что-то он слишком быстро слился со своего тейка "интегрировано в
> компилятор - значит часть компилятора". Наверное я его спугнул всё-таки и он почуял неладное.Балабол, твой "тейк" существовал лишь в твоей фантазии, а "спугнул" ты - своей "крутизной и умом", ага.
Любители "троллить тупостью" мне не интересны, тем более пошел вообще какой-то бред вида "компилятора, которого нет" и прочие унылые демагогические виляния классического, ткнутого носом в лужу, опеннетного кэксперта.
> Балаболка, ты ж сам - на них ссылся, в качестве "доказательства" своего "тезиса".Какой необучаемый. Но да ладно, побежал показывать, что я ссылался "в качестве "доказательства"", а не в качестве примера.
> У тебя ж вся цепочка "аргументации" построена на повторении на разные лады "в ЯП того-этого нет, потому что в компиляторе есть баг и его можно использовать".
Зачем агитатор, не могущий в элементарную логику, пытается рассуждать о чём-то и проецировать свои детсадовские представления на остальных?
> Балабол, твой "тейк" существовал лишь в твоей фантазии, а "спугнул" ты - своей "крутизной и умом", ага.
Ответить нечего, поэтому агитатор будет заспамливать меня клоунадой. Всё как я и говорил. Но ты попытайся, там далее интересно будет.
> вообще какой-то бред вида "компилятора, которого нет"
С этого агитаторов подрывает, да. А так, да - компилятора руста не существует. Всё что есть - парсер-нашлёпка поверх ворованного ллвм.
>> Этого нет в языке, а заявляется безопасность языка
>> into the compiler
> Кекспертиза изо всех щелей ...Вообще говоря это есть в языке. Не в стандарте правда, потому что стандарта нет, однако в Rust в целом описано какой семантике должны подчиняться заимствования, этот механизм эволюционирует, и условный gcc должен подчиняться этим требованиям
Lexical lifetimes -> non-lexical lifetimes (Это то что сейчас использует компилятор rustc по дефолту) -> stacked borrows -> tree borrows (Это то что может поймать любую подобную мискомпиляцию)
Подчиняться компиляторы должны tree borrows, однако дополнительно валидировать на уровне компилятора не выйдет, потому что он требует pointer provenance, условно с каждым указателем нужно носить дополнительные данные, железный аналог подобного - CHERI, а в Rust есть MIRI который используется для comptime вычислений, но который в том числе можно использовать и для того чтобы исполнять всю программу (пускай и медленно, ведь это интерпретатор Rust)
С cve-rs мы наблюдаем что валидатор (miri) багу ловит, а компилятор на неё не жалуется и позволяет нарушать гарантии. Почему он не жалуется? Потому что в компиляторе есть несколько багов, из за которых он пока не подчиняется tree borrows.
Так что в данном случае наоборот, у нас в языке всё это исправлено, а вот компилятор пока отстаёт.Однако обобщать такое неправильно, потому что код для того чтобы эти баги компилятора затриггерить нужен очень нетривиальный, и случайно ты его не напишешь, его долго выводили из более общих случаев, и сейчас почти все такие уязвимости минимизированы
В частности, cve-rs хоть и демонстрирует несколько уязвимостей (use after free, type confusion, buffer overflow, null pointer dereference), однако под капотом у всего этого лежит лишь один баг компилятора, который воспроизводится так:
pub const STATIC_UNIT: &&() = &&();
#[inline(never)]
pub fn lifetime_translator_mut<'a, 'b, T: ?Sized>(
_val_a: &'a &'b (),
val_b: &'b mut T,
) -> &'a mut T {
val_b
}
pub fn expand_mut<'a, 'b, T: ?Sized>(x: &'a mut T) -> &'b mut T {
let f: for<'x> fn(_, &'x mut T) -> &'b mut T = lifetime_translator_mut;
f(STATIC_UNIT, x)
}Это очень специфический код, который ты нигде в природе не увидишь
Но если коротко - то он позволяет получить для переменной которая живёт малое время, указатель который живёт дольшее время (что есть баг компилятора, и что язык запрещает), aka use-after-freeОстальные уязвимости там достигаются через type confusion - имея user after free, мы можем обращаться к освобождённой памяти, а значит если в ту память записать что-то другое - то мы общаемся с переменной типа A используя указатель на тип B
buffer-overflow - к короткому буферу обращаемся как к длинному
null-pointer-deref - к нулевому указателю обращаемся как к референсу (который не может быть null)
И т.д. Раньше в cve-rs было ещё больше багов на этой базе, но сейчас почти все отвалились уже при работе с обычным компилятором, а под miri они никогда не работали.Как только этот оставшийся баг будет исправлен, то весь cve-rs отпадёт
> А с учётом этого(https://github.com/Speykious/cve-rs) не-unsafe даже в мечтах не возможен.Как хорошо, что ты зашел почти сразу с козырей и показал свою "квалификацию" :)
Т.е. можно смело игнорить очередные, гневные "разоблачения" очередного, опеннетного кексперта.
Как хорошо, что тебе с первого же тейка нечего ответить и ты показал свою "квалификацию" :)
Т.е. можно смело игнорить очередные, отчаяные оправдания очередного, опеннетного кексперта.
> Как хорошо, что тебе с первого же тейка нечего ответить и ты
> показал свою "квалификацию" :)Не, кексперт - просто тебе и подобным уже отвечали на это 100500 раз и каждый раз вы почему-то сливались :)
https://www.opennet.me/openforum/vsluhforumID3/133387.html#122
https://opennet.ru/openforum/vsluhforumID3/133278.html#28
https://www.opennet.me/openforum/vsluhforumID3/134910.html#249
https://www.opennet.me/openforum/vsluhforumID3/136952.html#161
https://www.opennet.me/openforum/vsluhforumID3/136093.html#86
Но ты можешь попытаться выдать что-то, отличное от "вы фсе врети!", все в твоих руках.
> А с учётом этого(https://github.com/Speykious/cve-rs) не-unsafe даже в мечтах не возможен.Ну конечно, давайте сравнивать баги в компиляторе которые постепенно исправляют (https://github.com/rust-lang/rust/issues/25860, https://github.com/Speykious/cve-rs/issues/3) с UB который в сях есть по стандарту и который в общем случае не фиксится и не детектится ни на чьей стороне
> баги в компиляторе которые постепенно исправляют
> исправляютhttps://github.com/rust-lang/rust/issues/25860:
> opened on May 28, 2015
> OpenЧто линкует этот агитатор? Как обычно надеется что никто не прочитает, что там по ссылке?
> в компиляторе
https://github.com/Speykious/cve-rs/issues/3:
> Miri
Что линкует этот агитатор? Пытается заспамить какой-то мурой? Причём я отвечал на это выше.
> UB который в сях есть по стандарту
> по стандартуЧто несёт этот агитатор? Пытается манипулировать или просто не умеет в логику? У руста нет стандарта, поэтому все отсылки на стандарт несостоятельны.
> который в общем случае не фиксится и не детектится ни на чьей стороне
Что несёт этот агитатор? Они детектятся и на это я также отвечал. Не говоря уже о том, что сравнение снова несостоятельное, потому как руста без сей не существует.
https://users.rust-lang.org/t/i-finally-found-the-cheat-code...> I don't like that project. Through the ways of the internet is somehow got some spotlight, but AFAIK it doesn’t really contain any novelty, but builds on the oldest type-system unsoundness in the books, which is a known issue for almost a decade longer than cve-rs exists
https://github.com/rust-lang/rust/issues?q=is%3Aissue&#...
> Ну и понятно почему
> // This type is the same type exposed by Panthor's uAPI. As it's declared as
> // #repr(C), we can be sure that the layout is the same.Это всего лишь 1 unsafe. А эти для чего
+unsafe impl Send for TyrData {}
+unsafe impl Sync for TyrData {}?
>> Ну и понятно почему
>> // This type is the same type exposed by Panthor's uAPI. As it's declared as
>> // #repr(C), we can be sure that the layout is the same.
> Это всего лишь 1 unsafe. А эти для чего
> +unsafe impl Send for TyrData {}
> +unsafe impl Sync for TyrData {}Вам там че, запретили, под страхом отлучения от опеннета, глядеть в доки?
https://rust.docs.kernel.org/core/marker/trait.Send.html
> Types that can be transferred across thread boundaries.
> Types for which it is safe to share references between threads.
> This trait is automatically implemented when the compiler determines it’s appropriate.
> The precise definition is: a type T is Sync if and only if &T is Send. In other words, if there is no possibility of undefined behavior (including data races) when passing &T references between threads.
>
Ну вот и о какой тогда безопасности речь? Сами себе противоречите.
> Ну вот и о какой тогда безопасности речь? Сами себе противоречите.Я не в курсе ваших фантазий и уж тем более, что и чему там противоречит, увы.
> Ну вот и о какой тогда безопасности речь? Сами себе противоречите.А, у вас подход "сгорел сарай, гори и хата"?
О какой безопасности может идти речь, если раст-коду приходится взаимодействовать с си кодом, который не дает вообще ни каких гарантий.
Безопасным будет только раст код, а если что-то пойдет не так - спрашивайте сишников.
> О какой безопасности может идти речь, если раст-коду приходится взаимодействовать с си кодом, который не дает вообще ни каких гарантий.Во-первых это не так.
> Безопасным будет только раст код, а если что-то пойдет не так - спрашивайте сишников.
Смысл тогда делать обвязки, которые внутри будут вызывать "unsafe" код и стучать себя в грудь, заявляя "мы сделали на расте". Бред.
>Во-первых это не так.Именно так. Код на C не даёт никаких гарантий. Код на Rust - даёт.
>Смысл тогда делать обвязки, которые внутри будут вызывать "unsafe" код и стучать себя в грудь, заявляя "мы сделали на расте".
Смысл в том, чтобы изолировать опасный код от безопасного. Это же сразу видно и потом гораздо проще найти причину некорректного поведения программы.
Это код биндинга к сямКомпилятор Rustc видит там сырые указатели, и разумеется не понимает контекст к ним
Будут ли эти указатели валидны при передаче в другой поток, или они ссылаются на thread-local? Можно ли с этими указателями работать из нескольких потоков одновременно, или нужна синхронизация?Вот на стороне Rust и прописывают явно что там нам из сей вернуло, а именно то что эта структура ссылается на общие данные и не теряет смысла при передаче между потоками (Send), и то что в этой структуре нет мутабельных данных, она thread-safe, а соответственно синхронизация не нужна, и с ней можно работать из нескольких потоков (Sync)
Для структур что описаны целиком в Rust, и которым не нужно общаться с сишным кодом маркеры Send/Sync не нужны, потому что компилятор сам в состоянии вывести/доказать оба требования, проблемы идут только с вещами что компилятор не понимает - что там сишка своим API показать хотела
этот код говорит, что структуру можно отправлять из потока в поток, эту структуру можно вызывать в многопоточной среде без синхронизации.
Скорее всего авторы использовали структуру в которой сырые указатели, а про них раст ничего сказать не может так как это скорее всего сишное
Ну и какой смысл в этом? Обмазаться unsafe в самом важном.
Мда, похоже, некоторых сводит с ума само слово unsafe. Между тем оно было некогда выбрано не совсем удачно, и можно мысленно заменять его на trusted. То есть вызываем код, гарантии которого не может проверить компилятор, но может программист.
> Целых три ансефа на все изменения.ага, можно было обойтись одним
Геншин начнёт летать! Но только на Mali. Нет, вру. Летать он по-прежнему будет только на Apple M*. Это была точка зрения практического применения, спасибо за понимание.
> 600 строк кода, а шуму то...А тут сам факт важен. Сколько раз использовался аргумент у противников раста в ядре что "ни одного драйвера на расте нет". А теперь он инвалидирован, можно спрашивать "а почему им разрешили, а нам нет?" Ну и следующие патчи уже в пути.
>> 600 строк кода, а шуму то...
> А тут сам факт важен.Вот я про то же. Скоро будут писать как раст-разраб сходил поел.
> Сколько раз использовался аргумент у противников раста в ядре что "ни одного драйвера на расте нет".
Ну рабочего нет. Ничего не поменялось.
>Ну рабочего нет. Ничего не поменялось.зато готовы добавить дополнительную кучу абстракций в ядро :)
> если на одну кучу навалить другую кучу, то вышеупомянутая "одна" станет ширшеЗакон Раста
если раст разработчик поел небезопасно, то виновата эволюция дарвина или креативизм теологов.
так драйвер мигания светодиодиком уже ж давно есть.
Правда, он там для собственно мигания вызывает небезопастный си-код...а, стоп, тут такая же хрень.Интересней тут другое - наш дЭффективный менеджер всяго линукса поднимал визг в сотни децибел при попытке подсунуть ему код, дублирующий то что уже и так работает, и работает - хорошо. (Вместо замены с внятными объяснениями, зачем надо менять.)
А тут молчит и проглатывает.
Видимо, миллион долларов в месяц сам себя не выплатит.
>и G710т.е. второй Тензор:
https://en.wikipedia.org/wiki/Google_Tensor#Models
У... что сейчас начнется))А так, отличная новость.
Ядерщики конечно тормозят знатно, но патчи в ядро заходят.
И смотря на участников - Collabora, Arm и Google - становится ясно, что они дожмут.
Линух протух сразу как был форкнут с Миникса, вот туда и заходит всякое
Альтернативы?
https://opennet.ru/63382-freebsd
> https://opennet.ru/63382-freebsdКруто. А дрова все еще с линукса тырить будете?
А если они на расте будут, то что?))
> А если они на расте будут, то что?))то вот примерно это:
> Технология CSF, применяемая начиная с 10 поколения GPU Mali, примечательна выносом на
> сторону прошивки некоторых функций драйвера и задействованием новой модели организации
> Функциональность Tyr пока отстаёт от драйвера Panthor,то есть казалось бы, днище, падать некуда, и так от драйвера остался копипастинг блобов туда-сюда. Но нет, снизу стучат.
Ну и зачем кому-то сдалось "тырить" такой драйвер? Подождем пока microsoft для embedded windows свой напишет.
> то есть казалось бы, днище, падать некуда, и так от драйвера остался
> копипастинг блобов туда-сюда. Но нет, снизу стучат.Ну так сами своими гнутыми выбрыками с Ж0п0эль символами достали производителей железа.
Это нормально в патч-версии обновлении ядра ломать дрова?
Вот теперь кушаейте прошивку на чипах видяхи. А "свободный гнутый" драйвер будет ее туда просто свободно и гнуто грузить.
> Вот теперь кушаейте прошивку на чипах видяхи. А "свободный гнутый" драйвер будет
> ее туда просто свободно и гнуто грузить.так он, %@%@^#%^ и ЭТО тоже умудряется делать криво!
> Круто. А дрова все еще с линукса тырить будете?Почему "тырить"?
Там обычно таки "permission is hereby granted" (я так понимаю, это "исконно-посконная линуховая лицензия" - последние лет цать сообщество все более-менее работающие дрова под ней пишет и в ядро включает, а само шифруется под псевдонимами типа "штеуд" или "красная шапка")torvalds/linux/blob/master/drivers/gpu/drm/nouveau/nvkm/core/engine.c
> Permission is hereby granted, free of charge,drivers/gpu/drm/i915/gvt/kvmgt.c
> Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
> * Permission is hereby granted, free of chargedrivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c
> * Copyright 2019 Advanced Micro Devices, Inc.
> * Permission is hereby granted, free of charge,
>> Круто. А дрова все еще с линукса тырить будете?
> Почему "тырить"?
> Там обычно таки "permission is hereby granted"А что на счет напр. wifi?
wifibox просто так появился?))
https://genode.org/
Линукс написан с нуля и имеет лицензию копилефт.
Если он написан с нуля, то почему там исходники из Беркли и других мест?
> насчитывает чуть больше 600 строк кодаИз которых полезных дай бог 100, остальное руст болерплат. Очередной хэлворд, продвигающийся через руст, продвигающийся через хайп, админ-ресурс и госуху.
> +// SAFETY:
Иконка под стекло. Бгг.
Это ты еще не вчитывался:> Функциональность для взаимодействия с GPU Mali портирована из существующего DRM-драйвера
> Panthor (Direct Rendering Manager), написанного на языке Си. uAPI драйвера Tyr идентичен
> uAPI драйвера Panthor, что позволяет использовать с ним уже существующие компоненты
> пространства пользователя.т.е. собственно - драйвер, а не переключалку графрежимов.
И при всем при этом - мы переписькивали-переписькивали, но... уот:
> Функциональность Tyr пока отстаёт от драйвера Panthor,
т.е. еще и нихрена не работает (потому что mali и так ничего особенного не умеет)
В общем, хрустики пробивают очередное дно, но тут снизу настойчиво стучат.
>Это ты еще не вчитывалсяА вы вообще читать не умеете, похоже. Там же в статье написано, почему с таким скрипом идёт написание драйверов. Подсказка: в нынешнем ядре не хватает абстракций. Как добавят, что вы тогда запоёте?
>В общем, хрустики пробивают очередное дно, но тут снизу настойчиво стучат.
Всякие кексперты-растохейтеры из Опеннета :)
> Подсказка: в нынешнем ядре не хватает абстракций.Угу, обоcpaкций вам не хватает.
Ста прослоек к ста прокладкам. Без этого, конечно, ну никак.А как сишный код до сих пор без них обходился и почему супер безопастному нескучному йезычку с миллионом закорючек без них никак не выжить?
Что означает лицензия SPDX-License-Identifier: GPL-2.0 or MIT? Можно выбрать? Как это работает?
Вас в Интернете забанили?Я задал ваши вопросы LLM.
Что означает лицензия SPDX-License-Identifier: GPL-2.0 or MIT? Можно выбрать? Как это работает?
Лицензия с указанием **SPDX-License-Identifier: GPL-2.0 OR MIT** означает, что исходный код распространяется под **двойной лицензией**, и пользователь может **выбрать одну из двух лицензий** — либо GPL версии 2.0, либо MIT[1][2][3].
Как это работает:
- **"OR"** в SPDX выражении указывает на выбор лицензии. Это значит, что вы можете принять условия либо GPL-2.0, либо MIT, но не обе одновременно[1][2].
- Если вы выберете MIT, то для вашего использования и распространения кода применяются условия MIT (более свободные, не требующие открывать изменения).
- Если выберете GPL-2.0, то должны соблюдать условия GPL, которые требуют, например, открывать исходный код при распространении модификаций[3][4].
- Такая двойная лицензия даёт гибкость пользователям — они могут выбрать более подходящую для них лицензию.SPDX (Software Package Data Exchange) — это стандарт для однозначного указания лицензий в исходных файлах, что упрощает автоматическое определение и соблюдение лицензий[5][6].
Таким образом, запись
```
// SPDX-License-Identifier: GPL-2.0 OR MIT
```означает, что файл можно использовать либо под GPL-2.0, либо под MIT, и пользователь сам выбирает, какую лицензию применять[1][2].
Если бы стояло **AND** вместо OR, это означало бы, что нужно соблюдать условия обеих лицензий одновременно, что встречается в других сценариях, но не в данном случае[2].
Citations:
[1] license-rules.rst - The Linux Kernel Archives https://www.kernel.org/doc/Documentation/process/license-rul...
[2] Linux kernel licensing rules https://www.kernel.org/doc/html/v4.19/process/license-rules....
[3] Clarification: Dual licensed under the MIT or GPL Version 2 licenses https://opensource.stackexchange.com/questions/8811/clarific...
[4] MIT vs GPL license [closed] - Stack Overflow https://stackoverflow.com/questions/3902754/mit-vs-gpl-license
[5] Understanding and Using SPDX License Identifiers and ... - FOSSA https://fossa.com/blog/understanding-using-spdx-license-iden.../
[6] Solving License Compliance at the Source: Adding SPDX License IDs - Linux Foundation https://www.linuxfoundation.org/blog/blog/solving-license-co...
[7] Dual-Licensing Models Explained, Featuring Heather Meeker - FOSSA https://fossa.com/blog/dual-licensing-models-explained/
[8] LICENSE-GPL-2.0 · OpenHarmony/kernel_common_modules_newip - Gitee https://gitee.com/openharmony/kernel_common_modules_newip/bl...
[9] Type: LicenseExpression https://docs.finitestate.io/types/license-expression
[10] GNU General Public License v2.0 or later - SPDX https://spdx.org/licenses/GPL-2.0-or-later.html
[11] What are Some Common Open Source Licenses? https://fossid.com/articles/what-are-some-common-open-source.../
[12] Handling License Info - SPDX https://spdx.dev/learn/handling-license-info/
[13] Using SPDX license list short identifiers in source files - GitHub https://github.com/spdx/using/blob/main/docs/using-SPDX-shor.../
[14] SPDX License List | Software Package Data Exchange (SPDX) https://spdx.org/licenses/
[15] B. SPDX license expressions - SPDX Specification 3.0.1 https://spdx.github.io/spdx-spec/v3.0.1/annexes/spdx-license.../
[16] The SPDX License List - GitHub https://github.com/spdx/license-list-XML/blob/main/DOCS/faq.md
Чё, молодцы, упразднение опенсорсных драйверов идёт полным ходом под радостное хлопанье сопровождающих - им драйвера как кобыле пятая нога. Скоро будем созерцать "подключите девайс к Интернету, пройдите TEE-аттестацию и оплатите подписку для разблокировки 3D-возможностей".
> подключите девайс к Интернету, пройдите TEE-аттестацию и оплатите подпискуА какие минусы?
>упразднение опенсорсных драйверов идёт полным ходомКак вы сделали такой вывод?
>Скоро будем созерцать "подключите девайс к Интернету, пройдите TEE-аттестацию и оплатите подписку для разблокировки 3D-возможностей
Это где такое присутствует? И почему для опенсорсных драйверов такого быть не может? Открытый код не означает бесплатность.
Rust в Linux как бетонный каток диет по асфальту - медленно но верно! Процент кода Rust в ядре Linux будет только увеличиваться!
Но конечно же, вы всегда можете сделать форк ядра Linux без Rust)
> Но конечно же, вы всегда можете сделать форк ядра Linux без Rust)можем, но не будем - лучшей антирекламы хруста чем эти шестисотстрочные прослойки к прокладкам, только еще и неполнофункциональные, придумать невозможно.
> Но конечно же, вы всегда можете сделать форк ядра Linux без Rust)Разумеется!
Вот форк иксов уже сделали.
А сейчас сделают форк ядра. И заживееем!
21 год - 30 млн строк кода.
25 год - 40 млн строк кода.Сколько строк кода на rust?
А разве кто то написал что он УЖЕ всё заменил ? Через несколько лет будете спрашивать "сколько строк кода на си" . Если ещё будет о чём спрашивать .
Через несколько десятков лет? Или попросят весь мир подождать, пока актуальное ядро переписывают?
через несколько лет, если раст таки завезут в ядро, ты будешь раз в неделю бегать в магазин за новым железом, а ещё через несколько лет будет невозможно собрать ядро дома, и опенсорсный по сути проект станет проприетарным по фактубудешь смотреть рекламу на половину экрана или платить за подписку, чтобы смотреть на четверть экрана
и бежать тебе будет уже некуда
Не врёшь же, да?
Или лучше быть как местные старожилы, которые постоянно ноют, что на их четвёртом пне теперь перестало что-то заводиться, потому что в ядре что-то удалили.
Такими темпами как сейчас даже процент увеличивать не получится.
А сколько там строк "дрова от вендоров"?
Если завтра АМД притащит 5 лямов автогенерированных строк, но на расте, то их точно так же примут.
Потому что ты или жреш чо дали, или сидишь без дров.
> Rust в Linux как бетонный каток диет по асфальту - медленно но верно!Такими темпами рано или поздно ядра не станет. Помянем.
Как некогда лютый хейтер Раста, скажу: это неплохо.
Пусть драйвера будут на Расте, безопасность там совсем не будет лишней. А планировщик, переключение контекста и прочие таймеры пусть будут на Си - там где нужны максимальные производительность и быстродействие, нужно их обеспечить. Так же как и вставки на Ассемблере никуда не денутся - эту часть кода заменять только на LLVM IR.
> Так же как и вставки на Ассемблере никуда не денутся - эту часть кода заменять только на LLVM IR.Бег с молотком и спортивное прибивание гвоздями к одному компилятору.
> Пусть драйвера будут на Расте, безопасность там совсем не будет лишнейПроблема только в том, что "безопасность" на Расте кажущаяся, а не фактическая. Да еще и синтаксис костыльный. Переписывание драйверов на Раст не приведет к увеличению безопасности. Но ухудшит качество кода
> "безопасность" на Расте кажущаяся, а не фактическая.И ты готов привести какие-то доказательства своего утверждения?
> синтаксис костыльный
только для неосиляторов
> не приведет к увеличению безопасности.
Кажется у нас в треде целый разработчик ядра!
Странно, что другие типа Грега имеют отличное мнение)
> И ты готов привести какие-то доказательства своего утверждения?Out-of-bounds - толко в рантайме. Как и остальные языки.
integer overflow - только в дебаг сборках.Хотя data races и borrowing есть и это плюс.
> только для неосиляторов
Просто я не любитель кактусов. Да и глобального смысла в этом нет.
>Out-of-bounds - толко в рантайме. Как и остальные языки.Это C, что ли, вы решили отнести к остальным языкам?
>integer overflow - только в дебаг сборках
Не только. Включите опцию компилятора overflow-checks = true и радуйтесь жизни.
>Да и глобального смысла в этом нет.
Есть, конечно. Просто вы не в курсе, похоже.
а на си этих драйверов нет? просто чтобы знать, какое железо вендорлокнутое
Статью не пробовали читать целиком?
зачем?
600 строк - впечатляет. Если написали функциональный драйвер, уместившийся в эти 600 строк - можно похлопать👏.
Обычно кстати на Си любят таким заниматься, чтобы максимум функционала в минимальный объем кода - иногда даже выходит красиво.(Си минималистичен).
> Если написали функциональный драйвер,В новости про это есть
> Функциональность Tyr пока отстаёт от драйвера Panthor, но разработчики намерены постепенно сокращать разрыв до тех пор пока не будет достигнут паритет в возможностях драйверов.
Это просто заглушка по факту. Но фанатам раста нужна пища. Это отталкивает.
Нет бы прошивку планировщика написать.
На что только не пойдут проприерасты чтобы утащить свободный драйвер в фирмварь.
> Функциональность для взаимодействия с GPU Mali портирована из существующего DRM-драйвера Panthor (Direct Rendering Manager), написанного на языке Си.Поясните, кто в курсе - он взяли код на си и, глядя на него, написали код на расте с той же функциональностью, или написали обвязку на расте для сишной либы?
Да.
Да нет, наверное.
Обычно на таких системах памяти кот наплакал и за 8 гигабайт требуется выложить как за нехилый игровой ПК с видеокартой.
Теперь окошко Овертона сдвигают в сторону 16 гигабайт. Сдюжит ли арм с драйверами нарасте, которые ещё и собрать на нём в какой-то момент времени будет нельзя?
А сдюжит ли ваш карман к прибавке на каждый драйвер в каждый телевизор, холодильник, распберри и телефон?
Сколько глупостей в таком коротком сообщении. Да вы просто талант.>за 8 гигабайт требуется выложить как за нехилый игровой ПК с видеокартой
Нехилый игровой ПК стоит от двух тысяч долларов. Смартфон с 8 гигами на борту - около 150-300 долларов.
>Сдюжит ли арм с драйверами нарасте,
А в чем вы видите проблему? По требованиям к ресурсам драйвер на Rust будет точно таким же, как драйвер на C.
>которые ещё и собрать на нём в какой-то момент времени будет нельзя?
Откройте для себя кросс-компиляцию.
Хочешь безопасности в ядре - используй микроядро.Да, будет медленно. Относительно.
Но безопасно.
А игры с языком на уровне мега-моно-ядра - оно, извините, бессмысленно и глупо.
Каждый раз производительность будет упираться в ограничения языка, введённые для безопасности, ограничения будут зверскими усилиями разработчиков преодолеваться - в общем, работа ради работы.
>Каждый раз производительность будет упираться в ограничения языка, введённые для безопасности, ограничения будут зверскими усилиями разработчиков преодолеватьсяНекая доля истины в этом есть. Но не особо большая. Зверских усилий для этого делать не надо, все способы хорошо известны. Кроме этого, большинство абстракций в Rust бесплатны.
Если код открыт - это ради очередной параши очередной "нескучный кокомпидлятор" тащить.
Не нужно.Если закрыт - не мои проблемы на чем писали и нефиг трындеть.
Как ни крути а не новость а фигня.