LINUX.ORG.RU

Rust-for-Linux: Custom alloc, using stable Rust compilers, and more

 ,


0

4

Тут увидел симпатичный PR в Rust-for-Linux: https://github.com/Rust-for-Linux/linux/pull/402

Общий смысл: переписали alloc, что бы он не паниковал на каждый чих. Переходят на стабильный компилятор.

Немного примеров:

        for _ in 0..page_count {
            let page = Pages::<0>::new()?;
            page.insert_page(vma, address)?;
-            pages.push(page);
+            pages.try_push(page)?;
            address += 1 << bindings::PAGE_SHIFT;
        }

-        // TODO: This allocates memory.
-        let arc = Arc::from(pages);
+        let arc = Arc::try_from_vec(pages)?;

        // Save pages for later.
        let mut inner = self.inner.lock();
    fn read_all(&mut self) -> Result<Vec<u8>> {
        let mut data = Vec::<u8>::new();
-        data.try_reserve_exact(self.len())?;
-        data.resize(self.len(), 0);
+        data.try_resize(self.len(), 0)?;

        // SAFETY: The output buffer is valid as we just allocated it.
        unsafe { self.read_raw(data.as_mut_ptr(), data.len())? };

Надеются на слияние в 5.14

★★★★★

Ответ на: комментарий от anonymous-angler

Ага, часть файлов с

// SPDX-License-Identifier: Apache-2.0 OR MIT

Ещё остались скрытые паники в [] (и может ещё где-то). Одним переписыванием alloc панику в Rust не выличить.

З.Ы. Мысли в слух, вот бы нормальный nopanic режим, с доказательством безопасного обращения к элементам массива (и не только), один фиг оптимизатор умеет избавлять от паники в коде вида

fn second(xs: [i32]) -> Option<i32> {
  if i.size() < 2 {
     None
  } else {
     Some(xs[1])
  }
}
AlexVR ★★★★★
() автор топика

Не взлетит. В Java уже было такое в 90-х. Напоролись, до сих пор расхлёбывают. Растаманы, похоже, совсем на ошибках не учатся.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

В Java уже было такое в 90-х. Напоролись, до сих пор расхлёбывают.

Что такое?

AlexVR ★★★★★
() автор топика
Ответ на: комментарий от Legioner

Это не checked exceptions где не попадя, чтобы потом в пионерских утилитах делать бездумный try-catch потому что тебе пофиг на ООМ.

Тут можно и так и так - два метода доступно, но в ядре решили все-таки делать checked.

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

Вот интересно, что в следующий раз будет камнем преткновения? (Имею в виду вливание в 5.14)

AlexVR ★★★★★
() автор топика
Ответ на: комментарий от AlexVR

один фиг оптимизатор умеет избавлять от паники в коде вида

Ну slice тут read-only так что его не смогут в другом потоке поменять чтобы между проверкой и доступом по индексу была проблема.

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

vertexua ★★★★★
()
Ответ на: комментарий от AlexVR

Опять какая-то выдуманная проблема. Доступ за пределы массива - это баг, поэтому в юзерспейс коде он вызывает панику и/или приводит к завершению приложения. Не понимаю, почему с ядром должно быть иначе.

И да, код выше не является валидным растом. К тому же с точки зрения раста между len() и перегруженным оператором [] нет никакой связи.

Если нужно с проверкой, то есть .get(idx).

anonymous-angler ★☆
()
Ответ на: комментарий от anonymous-angler

Доступ за пределы массива - это баг, поэтому в юзерспейс коде он вызывает панику и/или приводит к завершению приложения. Не понимаю, почему с ядром должно быть иначе.

Ну это вопрос более теоретический. Сколько заявлений, что ХХ% ошибок - это переполнение буфера и Rust позволит это решить. А по факту он предлагает только частичное решение этой проблемы.

И да, код выше не является валидным растом.

Каюсь. https://godbolt.org/z/fM83rvYhf

Я к чему, вот оптимизатор вырезал не используемый вызов panic. почему бы (теоретически) не заложить возможность на этапе компиляции выявлять возможные проблемы, как это, например, задумано в C++ c noexcept?

AlexVR ★★★★★
() автор топика
Ответ на: комментарий от AlexVR

Ну это вопрос более теоретический. Сколько заявлений, что ХХ% ошибок - это переполнение буфера и Rust позволит это решить. А по факту он предлагает только частичное решение этой проблемы.

Для начала бы неплохо было установить, что предлагаемое тобой возможно в общем случае, а не только приведённом выше - частном. Идея то хороша, но насколько она реализуема и какой ценой - не совсем ясно. В том же haskell вроде нет паники, но цена похоже оказалась неприемлимой для большинства.

Я к чему, вот оптимизатор вырезал не используемый вызов panic. почему бы (теоретически) не заложить возможность на этапе компиляции выявлять возможные проблемы, как это, например, задумано в C++ c noexcept?

noexcept не запрещает исключения, а только приводит к вызову terminate() если таковое случилось. Т.е. noexcept - это не гарантия отсутствия исключений, лишь гарантия того что программа не продолжит работу, если таковое случилось. Ну например, сделаю я объявление функции вроде extern "C" int foo() noexcept;, а затем определю где-нибудь эту функцию и брошу в ней исключение. Т.е. механизм почти 1-в-1 как паника с кастомным обработчиком.

anonymous-angler ★☆
()
Ответ на: комментарий от fsb4000

Да. Потому что конкретно здесь функция объявлена и определена в одном месте и у компилятора есть такая возможность. Но если я её определю в другом compilation unit без nothrow, а затем слинкую, то компилятор скорее всего уже не сможет определить проблему. Т.е. для гарантии что не будет panic/throw нужно что бы у компилятора был доступ сразу ко всему коду. А это не так то просто.

anonymous-angler ★☆
()
Последнее исправление: anonymous-angler (всего исправлений: 1)
Ответ на: комментарий от vertexua

По-мне суть та же. Что в жаве задолбаешься постоянно проверять исключения, что тут.

Впрочем ладно, в жаве одна из проблем - многословный синтаксис и необходимость писать throws XXX. Тут этой проблемы нет, может и нормально будет. В любом случае лучше, чем в C, и на том спасибо.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 2)
Ответ на: комментарий от Legioner

Как может быть суть та же?

В Java открытие файла сделали checked exception. Под раздачу попали школьники, бывшие пицценосцы и вообще кто угодно кому вообще нафиг не сдалась надежность в их коде.

В Rust сделали и так и так - сам выбирай. Раньше был только паникующий вариант. Он подойдет для любой write-only лапши, скриптов и так далее. Но теперь добавили альтернативу.

Те, кто хотят ввести дисциплину в каком-то критическом компоненте могут заенфорсить правило чтобы там всегда были непаникующие методы. Теперь у них есть возможность. А то раньше обычный push в вектор мог упасть с ООМ. Тут пол ЛОРа всиралось от радости по этому поводу, вот мы мамкины какеры знаем как покакать Раст. Теперь - если ты хочешь это без приседаний поймать ООМ и продолжить работу - можешь

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 5)
Ответ на: комментарий от anonymous-angler

В том же haskell вроде нет паники, но цена похоже оказалась неприемлимой для большинства.

Есть в хаскеле паника, не надо вводить людей в заблуждение.

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Слишком много придётся писать с нуля. Оно им надо?

А для всякого труЪ-ультра-хардкор эмбедеда есть no_std.

WatchCat ★★★★★
()
Ответ на: комментарий от anonymous

Например в определенном древе кода забанить конкретный список паникующих методов в стандартных библиотеках. В зависимости от стуации посмотреть список зависимостей и включить в них то же самое. По сути просто линтер. 100% покрыть не совсем обязательно, потому что баги случаются и задача не разрулить параною и проблемы с головой разработчика, которые боится сферическую панику в вакууме. Конечно для какого-то медицинского или космического применения нужно покрыть 100%. Просто для влкючений Rust модулей в ядро можно покрывать на 100%, это уже будет давать плюс

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от anonymous

И что? Rust разрабатывался в первую очередь для своих фишек которых в сишечке нет и никогда не будет, в силу направления развития.

А так, под Линем в Rust используют libc, под виндой используют какой-нибудь mswincrt.

Растишка планировался в том числе и для простого ffi-вызова сишечных функций.

WatchCat ★★★★★
()
Ответ на: комментарий от WatchCat

Зачем ты каждый раз позоришься? Ты никогда не сможешь показать никаких фишек в твоё бездарном недоязычке.

А так, под Линем в Rust используют libc, под виндой используют какой-нибудь mswincrt.

Без ворованного рантайма недоязычек ничего не может. Это не новость. Зачем ты декларируешь свои сектантские мантры?

Растишка планировался в том числе и для простого ffi-вызова сишечных функций.

Ну да, дёргать готовое апи(ворованное) - это потолк недоязычка.

anonymous
()
Ответ на: комментарий от vertexua

Кстати, как интересно. Ранее сектанты кукарекали про «в си нет разделения, а у нас явный unsafe на уровне языка, а не сторонней приблуды». И что же мы видим теперь? Правильно - дошколята как всегда обгадился и вот уже пошли рассказы про «проблемы с головой разработчика».

Та же история была с безопасностью(фэйковой), исключениями(которые дошколята пытаются бездарно эмулировать через unwrap/?), системностью(с биндингами к си) и всем остальным, о чём заявлял пропаганда недоязычка.

anonymous
()
Ответ на: комментарий от anonymous-angler

Т.е. механизм почти 1-в-1 как паника с кастомным обработчиком.

Зачем ты пишешь это? Очевидно что у запартных клоунов все механизмы(ворованные) будут 1-в-1(не почти, точно) как и у чего-либо ещё.

anonymous
()
Ответ на: комментарий от anonymous

Тебе доктор прописал выпить успокоительного и в кроватку. Ты почему нарушаешь режим?

WatchCat ★★★★★
()
Ответ на: комментарий от X512

То есть делают особую версию Rust для ядра не совместимую с обычной?

Никакой разницы с особой версией си не совместимой с обычной для ядра. Притом у раста вся несовместимость будет на уровне библиотек, а у си все хуже, требуются нестандартные расширения gcc.

anonymous
()
Ответ на: комментарий от anonymous

Как может быть «особая версия» язычка без стандарта и одним компилятором? Что ваш господин растоначальник скажет, то вы на ус и намотаете причмокивая от удовольствия. А ваша так называемая «несовместимость на уровне библиотек» означает то, что каждый будет таскать в довесок к ядру ещё и её.

А примеры вашего «вхождения» куда-нибудь вызывают улыбку. Пример - си либа notcurses, прикрутила к себе раст интерфейс, теперь ПОЛОВИНУ проекта занимает эта какашка в которой unsafe на unsaf’e (целых 500 блоков)! И это ещё без «особой версии библиотеки».

Чего-то как-то хлопотно пускать к себе в проект растофилов, какая-то подтирка соплей и вечное создание тепличных условий, чтобы не дай бог дите не поранилось.

anonymous
()
Ответ на: комментарий от anonymous-angler

В очередной раз мусор уничтожен одним заходом.

Для тех, кто не в курсе: данный деревенский поехавший был пойман на базовом балабольстве «сегфолт в c++» и умножен на ноль. Что же можно видеть здесь? Теперь дошколёнок уже знает, что против меня он обречёно и плывёт с первого же вопроса, начиная спамить рандомную херню.

anonymous
()
Ответ на: комментарий от anonymous

Как может быть «особая версия» язычка без стандарта и одним компилятором?

С одним компилятором как раз не проблема жить без стандарта, у Си в течении 16 лет или у С++ в течении 15 лет без стандарта и с кучей несовместимых компиляторов все было гораздо хуже.

Пример - си либа notcurses, прикрутила к себе раст интерфейс, теперь ПОЛОВИНУ проекта занимает эта какашка в которой unsafe на unsaf’e (целых 500 блоков)!

Это код генерированный rust-bindgen.

anonymous
()
Ответ на: комментарий от anonymous

С одним компилятором как раз не проблема жить без стандарта

Не проблема. Но говорить о «особой версии» при таком «дано» - глупость, конечно её не будет. А если захотят запилить свой компиль мелкомягкие, например, то получите на выходе то же самое, и стандартизироваться побежите.

Это код генерированный rust-bindgen.

Честно говоря - вообще пофиг чем, это ненормальная ситуация, когда какая-то обвязка сбоку занимет больше основного кода (скорее всего больше, т.к. там примеры на с/с++, наверное много). К себе бы я такое не пустил, если бы это «творчество» уложилось в несколько процентов, то ещё бы подумал.

anonymous
()
Ответ на: комментарий от X512

То есть делают особую версию Rust для ядра не совместимую с обычной?

У авторов жгучее желание использовать Box, Vec и т.п.. Но это из alloc (+std) для юзерспейса. Попробовали стандартный alloc, и заслуженно получили люлей за panic (когда-то давно было решено, что краткость кода за счёт паники предпочтительней). Сейчас перешли на стабильный core + подправленный alloc (раньше били на нестабильной сборке). В рамках развития стандартной библиотеке идут те же работы, но это ещё требует стабилизации.

Так же в рамках стандартной библиотеки идут работы по поддержи кастомных аллокаторов. И надо понимать, что стандартная библиотека в Rust не определяется стандартами как в C++ и над ней идёт куча экспериментов в рамках unstable. Плюс она состоит из нескольких частей, которые можно выбирать, плюс есть опции.

Язык от этого не меняется. Могли бы сделать свою версию no_std библиотеки для ядра с блэкджеком и шл., но почему-то решили мучить alloc. Может есть реальная возможность влиять на стандартные библиотеки. А может у авторов мало опыта в Embedded Rust. А может лень победила на первом этапе. А может таскать копии Arc, Rc, Vec, Box и т.д. реально глупая затея.

Но как бы то не было, всё это хороший повод причесать стандартную библиотеку.

AlexVR ★★★★★
() автор топика
Ответ на: комментарий от anonymous-angler

В 2к21 можно и без линковки обойтись. А если серьезно, то странный подход ожидать хоть какие-то гарантии от языка, не давая ему доступа к исходному коду.

anonymous
()
Ответ на: комментарий от anonymous

Никакой разницы с особой версией си не совместимой с обычной для ядра.

Это только в Линуксе так. В *BSD, Haiku, Zirkon, Serenity используется обычный C/C++ и доступны большинство стандартных заголовков.

X512 ★★★★★
()
Ответ на: комментарий от X512

В таком случае и раст на них сможет пользоваться большинством своих стандартных модулей.

anonymous
()
Ответ на: комментарий от AlexVR

Могли бы сделать свою версию no_std библиотеки для ядра с блэкджеком и шл., но почему-то решили мучить alloc.

Я думаю это потому что это в целом полезные изменения для самого Rust. Просто перспектива включения в ядро теперь позволяет найти причину выделить под это время в высоком приоритете

Rust в ядре - это очень крутой сигнал стабильности языка и надежности инвестиций

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от X512

Это только в Линуксе так

В Windows тоже так :(

Когда спросили кого-то там из Microsoft, когда они добавили clang при установке Visual Studio вторым компилятором, означает ли это, что теперь cl легаси, и вы переходите на clang, тот ответил, что нет, так как clang не может собрать Windows. И у них нет планов по прекращению разработки cl и перехода на clang.

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от anonymous

Так а с паникой что? Расто либа без них никак.

Если как пишут выше:

используется обычный C/C++ и доступны большинство стандартных заголовков

то значит что доступны исключения С++ и никаких проблем с паникой раста не будет.

anonymous
()
Ответ на: комментарий от anonymous

то значит что доступны исключения С++ и никаких проблем с паникой раста не будет.

Вопрос №2 - кто тебе сказал, что исключения нельзя обрабатывать в модуле ядра? Для этого нужно всего лишь реализовать некоторый интерфейс и всё, вот в этой статье https://monoinfinito.wordpress.com/series/exception-handling-in-c/ человек в исследовательских целях самостоятельно их обрабатывает. Короче очередная сказка растаманов об ужасном с++. Поэтому нет никаких принципиальных ограничений для его ++ стд работать в ядре. А с растом же история другая - все было сделано для удобства рядовому школьнику и сильно ограничено по возможностям, короче только садиться и переисывать.

anonymous
()
Ответ на: комментарий от vertexua

По-хорошему для этого нужен какой-то модификатор типа nopanic и поддержка в языке этих гарантий.

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

Ух ты, на уровне библиотеки сделали то, про что я только что написал, вот это реально круто, не знал, что в Rust такое возможно. Правда на первый взгляд выглядит, как хак и сообщение об ошибке ужасное, поэтому всё же на уровне языка было бы лучше. Но это уже мелочи.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 3)
Ответ на: комментарий от anonymous

Линусу все это объясни.

Теперь нет смысла объяснять ему на пальцах, так как он сам не может (нельзя) объяснять на пальцах. Теперь новая реальность - постковидная, то есть, постсжвшная - маски и перчатки без пальцев, то есть, варешки - пишем и разговариваем преодолевая трудности, чтобы инвалиды и прочие больные не чувствали себя ущемленными.

anonymous
()
Ответ на: комментарий от vertexua

Просто перспектива включения в ядро теперь позволяет найти причину выделить под это время в высоком приоритете

На сколько помню, выделили деньги только на одного человека.

AlexVR ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.