В течение всего февраля мы были делимся различными новостями на в случае возникновения проблем и разногласий которые были созданы в сообществе разработчиков ядра Linux для разработки на Rust.
даже Некоторые из тяжеловесов сообщества высказали свою позицию и что еще хуже, некоторые ушли со своих должностей в качестве сопровождающих в некоторых подсистемах ядра Linux.
Учитывая эту волну обсуждений, которая, похоже, выходит из-под контроля, Линус Торвальдс взял ситуацию в свои руки. y присоединился к обсуждению вокруг к сопротивлению некоторых разработчиков внедрению Rust в ядро Linux.
По словам Линуса, ни один специалист по сопровождению не обязан изучать, использовать или даже рассмотреть код, написанный на Ржавейте, если вам это не нужно, поскольку они могут продолжать работать исключительно с C.
В среду, 19 февраля 2025 г. в 22:42, Кристоф Хеллвиг написал:
>
В документе указано, что для использования Rust не требуется никакой подсистемы. Это доказано.
> ошибаетесь по отношению к Линусу. И хотя вы, возможно, не знали этого, когда
> Когда вы писали документ, вы, безусловно, сделали это, разместив его в списке.Я надеялся и попробовал, чтобы посмотреть, даст ли эта длинная ветка результаты.
во что-то конструктивное, но это, кажется, идет в обратном направлении (или, по крайней мере,
по крайней мере не вперед).Дело в том, что запрос на извлечение, против которого вы возражали, НЕ КАСАЕТСЯ DMA
СЛОЯ ВООБЩЕ.Он был буквально просто еще одним пользователем, находящимся в совершенно иной ситуации.
подкаталог, который никак не изменил код, который вы поддерживаете,
форма или вид.
ОднакоЕсли сопровождающий решит не вмешиваться, у него или нее также не будет возможности влиять ни в способе его разработки, ни в том, как его внешние ссылки интегрируются в код его собственной подсистемы.
Торвальдс объяснил, что те специалисты, которые заинтересованы в продвижении вперед с ржавчиной смогут участвовать в его развитии, влиять на строительство ссылок и помощь в обслуживании соответствующих интерфейсов. И наоборот, те, кто решит не работать с Rust, будут защищены от проблем, которые могут возникнуть при его использовании, но они также будут лишены возможности влиять на его развитие. Такой подход создает своего рода барьер, который, защищая тех, кто предан исключительно языку Си, в то же время не позволяет им вносить вклад в улучшение интеграции Rust.
Так что это письмо не о какой-либо «политике Rust». Это письмо о
Гораздо большая проблема: как разработчик, вы отвечаете за свой код,
Конечно, но вы не отвечаете за то, кто и как использует конечный результат.Вам не обязательно должен нравиться Rust. Вам не нужно беспокоиться о нем. То есть…
С самого начала было совершенно ясно, что никто не
вынуждены внезапно выучить новый язык, и что люди, которые
Если вы хотите работать исключительно на стороне С, вы можете продолжать это делать.
Такая ситуация создает своего рода защитный барьер.для тех, кто работает только с C, изолируя их от сложностей и потенциальных недостатков, связанных с этим к коду Rust. Но в то же время эта же изоляция не позволяет им влиять на прогресс Rust, а это значит, что девиз «никто не должен иметь дело с Rust» не позволяет каждому разработчику блокировать любой код, написанный на этом языке.
La организовано разделение обязанностей Таким образом, те, кто интересуется Rust, могут работать над его аспектами, в то время как те, кто решит не участвовать, не будут вынуждены менять свой рабочий процесс, хотя они и не смогут модифицировать разработку компонентов, написанных на Rust.
Споры усилились, когда встал вопрос об одобрении ссылок Rust через подсистему DMA. В этом случае возражения разработчика, пытавшегося заблокировать принятие таких ссылок, были проигнорированы, и Линус открыто критиковал действия Кристофа Хелльвига.
По словам Торвальдса, Хеллвиг превысил свои полномочия. пытаясь повлиять на код, который, будучи реализованным в отдельном подкаталоге, не влиял на подсистему DMA, за которую он отвечал. По словам Торвальдса, позиция Хеллвига аналогична попытке отключить DMA в контроллере просто потому, что он ему не нравится, что неприемлемо.
В конечном счете, хотя каждый сопровождающий несет ответственность за свой собственный код, от него нельзя требовать контролировать, как этот код используется, или принимать решения о его интеграции в более крупные проекты.