Rust в Ядре

Я хочу увидеть что пошло не так

Твои желания не то чтобы играют большую роль, но я рад, что ты чего-то ещё хочешь. Некоторые вот уже давно мертвы внутри и ничего не хотят.

Всё равно непонятно как операционка, для которой я (в том числе) пишу прикладные программы, в том числе, взаимодествуя с ядром, превращается в микроядерную после установки той или иной переферии.

Linux никак не превращается в микроядерную ОС из-за взаимодействия с другой микроядерной ОС. Не знаю, откуда ты вообще взял подобную идею.

Так - то у меня браузер может взаимодеиствовать с каким-нибудь кубером за морем. Так что теперь - у меня на ПК кубер?

Нет. Но твой ПК является сетью из нескольких компьютеров с разными ОС. То, что тебе об этом неизвестно, не означает, что это не так.

В общем-то, это всё нас возвращает к изначальному тезису, что микроядра почему-то не взлетают, в который так верят люниксисты. В реальности же микроядра взлетели и используются повсеместно, о чём я тебе здесь и рассказал.

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

У меня android, а значит ядро linux.

в русте строки и срезы - utf8

И это правильно. В 16 бит юникод всё равно не влезает. Так что это лишнее усложнение.

вот только внутренее кодирования строк в виндвс, java, сишарп и Net - utf16 и это жжж неспроста.

вот только внутренее кодирования строк в виндвс, java, сишарп и Net - utf16 и это жжж неспроста.

Это из-за легаси. С UTF-16 стараются слезать все кто может.

Другой вопрос, что строки в Rust не только Utf-8. Для системного API там отдельный тип строк.

Но это все равно чушь. Язык Си простой как барабан. Что там можно не выучить — непонятно, тот же Rust гораздо запутаннее.

Как уже выше писали, то что язык простой, ещё не означает, что на нем будет просто вести разработку. Потребуются как минимум знания предметной области. См. например эту тему - Мультитред, чтение меняющейся переменной без локов

знания предметной области требуются по любому. вне зависимости от языка. а язык будет считаться адекватным предметной области, если на его сущности и концепции предметная область отображается хорошо. ну или «адекватно».

некоторые организации, имеющие влияние на сферы применения линукса, усиленно создают сишке репутацию «небезопасного языка»

А мне казалось, что это разработчики на сях, которые постоянно выходят за границы массивов, используют очищенные переменные и копируют данные в чужую память создают такую репутацию.

Потребуются как минимум знания предметной области. См. например эту тему - Мультитред, чтение меняющейся переменной без локов

Вот там как по мне все просто. Если память это отображение пространства ввода/вывода устройства то нужен volatile. Если нужна синхронизация данных или атомарные изменения в памяти то атомики. Если невозможно использовать атомики из-за невыровненной памяти то volatile, возможно с барьерами памяти.

В прикладном программировании практически всегда выбор это атомики. При работе с устройствами либо при разработке под микроконтроллеры это volatile. Всё остальное это какая-то экзотика.

у utf8 из преимуществ только одно - компактность для латиницы. и обратная совместимость для ascii. все остальное - плохо. по сути utf8 - это ода англоязычности.

для всех, кому англоязычность по барабану, utf8 - еще тот головняк. им выгодней utf16. а все что не лезет в два байта, вообще можно рассматривать как атавизм.

utf8 - еще тот головняк. им выгодней utf16. а все что не лезет в два байта, вообще можно рассматривать как атавизм.

Ты ведь понимаешь что к примеру буква ‘й’ может состоять как из одного так и двух codepoint-ов? То-есть в utf16 будет занимать либо два либо четыре байта и уже нельзя считать что символ равен двум байтам. А если еще добавить эмодзи, то получится что выгоды у utf16 никакой.

Ты ведь понимаешь что к примеру буква ‘й’ может состоять как из одного так и двух codepoint-ов?

у жопоруков с вынесенными мозгами буква й вообще может занимать целое предложение. у нормальных людей это должен быть одиночный символ. ибо это й символ алфавита, а не составной иероглиф.

ы - тоже будем делать составным?

В общем-то, это всё нас возвращает к изначальному тезису, что микроядра почему-то не взлетают, в который так верят люниксисты.

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

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

ы - тоже будем делать составным?

Я для примера привел, можно другие алфавиты рассмотреть у многих там всякие точки/тире/и т.д. над/под буквами. Иногда чтоб не раздувать делают составные а не отдельные символы, можно погуглить примеры но мне лень. Просто факт что работать с utf16 считая что буква именно 2 байта нельзя. Да и мало где нужно работать с отдельными символами, обычно надо найти/заменить подстроку а тут без разницы urf8 или utf16 просто работаешь как с массивом байт и всё.

При том, что у тебя в телефоне несколько ядер ОС, и Linux – только одно из них. В остальных случаях, Linux не прошёл сертификацию по требованиям безопасности. А микроядра прошли. Короче, лялекс сосёт.

Некорректный вывод. Главное требование к «безопасности» в сотовых телефонах - это огороженность модемной части, чтобы даже при большом желании юзер ее не заюзал как-нибудь не так, как хочется FCC и другим надзорам. Еще и чтобы даже в принципе не знал, что эта часть делает на самом деле.

Linux в эту огороженность не вписывается уже только из-за своей лицензии. Его конечно научились тивоизировать и прикрывать, но все это не совсем то.

Кроме того, чисто технически, линукс слишком жирен для микроконтроллеров в модемных частях.

А микроядра прошли.

На практике микроядра прошли для специализированных ОС. Я даже затрудняюсь сказать есть ли сейчас хоть сколько-то широко используемая универсальная ОС общего назначения на микроядре?

Даже MacOS давно гибридная и мало, чем от монолитной отличается. WinNT когда-то была как бы микроядерной, но еще в 90-х ее стали усиленно разбавлять, а сейчас Win10/11 язык не повернется назвать микроядерной.

Minix3 вроде как бы есть, но чтение Hardware requirements и процесса установки нагоняют тоску https://wiki.minix3.org/doku.php?id=usersguide:hardwarerequirements http://www.minix3.org/doc/setup.html Она не поддерживает usb, современные диски, даже похоже не поддерживает видеокарты, за исключением тех, что поддерживает какая-то древняя версия иксов.

В общем, Minix3 в смысле широкой пригодности реально выглядит не лучше, чем Gnu/Hurd, может и хуже даже.

Ну и где микроядро?

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

Minix3 вроде как бы есть

В каждом Intel процессоре в составе Intel ME =).

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

Вот только на практике выяснилось, что есть нюансы, как говорится. В частности, оверхед на переключение в пользовательский режим для работы драйвера, убивает производительность. Поэтому даже в изначально микроядерных ОС стали затаскивать видеочасть в ядро.

И вообще, добиться согласованной работы всех систем в микроядре оказалось не так просто.

ЕМНИП, в немецком языке есть приколы, типа когда символ заглавный, это одна буква, а когда строчный то две. В любой кодировке будут нюансы при применении метода capitalize, а если язык нам позволит прихранить индекс символа, и далее получать его за O(1), то возникнут интересные эффекты.

В каждом Intel процессоре в составе Intel ME =).

Как узкоспециализированная система для специфических задач. Ну и полная огороженность, зачем-то ведь ее там не только нельзя модифицировать, но даже посмотреть не то, что на исходный код, даже на машинные коды - все пошифровано.

Внезапно: символы больше 2048 в utf-8 занимают 24бита а в utf-16 16бит …

Ну тут эффект полумер, просто выгнать какие то части из ядра на костылях не дает ожидаемого эффекта. А разрабатывать наноядерную архитектуру с чистого листа можно себе позволить только сугубо в исследовательских целях. ОС без программ библиотек и драйверов мало кому нужна

Внезапно: символы больше 2048 в utf-8 занимают 24бита а в utf-16 16бит …

Символы с 2048 по 65535 в utf-8 занимают 18 бит (3 байта по 8 бит). Зато не надо заморачиваться с BigEndian/LittleEndian.

Символы после 65535 и в utf-8 и в utf-16 занимают 4 байта.

В противоположность символы до 128 в utf-8 это один байт а в utf-16 два байта. А это HTML/XML/Json/etc.

Другие строки костыляют на макросах: https://docs.rs/uefi/latest/uefi/prelude/macro.cstr16.html

Символы после 65535…

ты хоть один такой символ знаешь? это шумерская клинопись, или узелковое письмо ацтеков небось. ну или первая буква алфавита какого-нить азиатского народа, последнего представителя которых затоптал слон в 1965 году.

А это HTML/XML/Json/etc.

о чем и речь. сам по себе утф8 - это гуано, но в силу вебщины с ее хтмльщиной, и прочими латинообразными форматами - этот утф8 насадили на палку и машут как знаменем.

попробуй вот редактор текста написать, если внутренее представление - utf8. чтобы найти только начало пред. символа, надо сканировать от начала строки. ..ну ладно. не от начала, но все равно извращенным образом. карочи фиксированное представление символа резко упрощает всю эту возню.

чтобы найти только начало пред. символа

Как будто с utf-16 не надо искать начало предыдущего символа, так как в контексте текстового редактора имеет смысл понятие глиф(по простому цельный символ), а он может состоять из нескольких codepoint. Банальный пример это любой окрашенный или составной эмодзи.

Уж если писать редактор текста так и надо делать массив индексов глифов а не с сырым utf-8/utf-16 работать. При чём можно делать конвертацию глифов из utf-8/utf-16 во внутренне представление 2 или 4 байтное, с которым уже реально можно работать по отдельности.

Уж если писать редактор текста так и надо делать массив индексов глифов а не с сырым utf-8/utf-16 работать.

вот тут самая экономия и попрет. особенно приятно если однобайтовый «глиф» заменить на 3 байтовый например, или вставить непонятный кусок utf8 кода в текущую позицию в тексте.

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

а еще прикол в том, что если вдруг латиница почему либо перестанет быть базовым символьным набором,(ну там всякие ветры перемен и исторические процессы) utf8 тут же окажется неудобным и все потребуют «пересмотра ценностей»!

особенно приятно если однобайтовый «глиф» заменить на 3 байтовый например, или вставить непонятный кусок utf8 кода в текущую позицию в тексте.

И чем это отличается от ситуации когда при utf-16 надо вместо 2 байтового глифа вставить 4 байтовый глиф? Или кусок utf-16 текста вставить в текущую позицию? Это стандартная ситуация когда по ходу редактирования текста в каких-то местах удаляется/добавляется текст.

а давайте в нашем гипотетическом редакторе 4 байтовые глифы на рассматривать. я уж сказал, что последнего кто знал, что расположено за 16битной границей затоптал слон в какой-нить тайской провинции.

естессно, если у вас вдруг появится необходимость выйти за 16 бит, надо переходить к внутреннему 4 байтовому представлению.

у жопоруков с вынесенными мозгами

Так и будешь в справке к своей программе писать? Кроме шизов вроде Эдика и Столярова никто не будет разбираться какие у него символы. Надо чтобы работало на всём.

Если бы в utf16 железобетонно влезал один любой символ, то это было бы решающим преимуществом. Но не влезает. В итоге си-шарпы и джавы просто обосрались со своими кодировками. И винда туда же. Нужно было подёргать юникодный winapi, так я там проклял эти сраные wchar’ы.

Гы:

[PATCH v8 2/2] rust: add dma coherent allocator abstraction.

+#[derive(Clone, Copy, PartialEq)]
+pub struct Attrs(pub u32);
- u32?
+
+impl Attrs {
+    /// Get the raw representation of this attribute.
+    pub(crate) fn as_raw(self) -> usize {
- usize?
+        self.0.try_into().unwrap()
+    }

+        let ret = unsafe {
+            bindings::dma_alloc_attrs(
+                dev.as_raw(),
+                size,
+                &mut dma_handle,
+                gfp_flags.as_raw(),
+                dma_attrs.as_raw(),
+            )
+        };

void *dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle,
		gfp_t flag, unsigned long attrs);

- unsigned long?

естессно, если у вас вдруг появится необходимость выйти за 16 бит, надо переходить к внутреннему 4 байтовому представлению.

Смотри если тебе в твоем текстовом редакторе мешает utf-8 и тебя устраивает utf-16, так просто конвертируй это дело из utf-8 в utf-16 при чтении и обратно при записи/копировании в буфер обмена. Кто-то тебе запрещает использовать utf-16/utf-32 как внутреннее представление? Мне от utf-8 достаточно уже того что он не зависит от Endian.

И это:

impl<T: AsBytes + FromBytes> CoherentAllocation<T> {
    /// Allocates a region of `size_of::<T> * count` of consistent memory.
    ///
    /// # Examples
    ///
    /// ```
    /// use kernel::device::Device;
    /// use kernel::dma::{attrs::*, CoherentAllocation};
    ///
    /// # fn test(dev: &Device) -> Result {
    /// let c: CoherentAllocation<u64> = CoherentAllocation::alloc_attrs(dev, 4, GFP_KERNEL,
    ///                                                                  DMA_ATTR_NO_WARN)?;
    /// # Ok::<(), Error>(()) }
    /// ```
    pub fn alloc_attrs(
        dev: &Device,
        count: usize,
        gfp_flags: kernel::alloc::Flags,
        dma_attrs: Attrs,
    ) -> Result<CoherentAllocation<T>> {
// ...
        let ret = unsafe {
            bindings::dma_alloc_attrs(

Чел в чём-то прав. grep dma_alloc_attrs ему ломают какой-то странной абстракцией.

Сейчас бы в 2025 году относиться к программному коду как к тексту и пользоваться грепом…

Чел в чём-то прав. grep dma_alloc_attrs ему ломают какой-то странной абстракцией.

Прям интересно стало что за dma_alloc_attrs:

Warning: These pieces of the DMA API should not be used in the
majority of cases, since they cater for unlikely corner cases that
don't belong in usual drivers.

If you don't understand how cache line coherency works between a
processor and an I/O device, you should not be using this part of the
API at all.

::

	void *
	dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle,
			gfp_t flag, unsigned long attrs)

А в документации прямо сказано что это для экзотических случаев для тех кто знает что делает.

Современный сишный компилятор tcc прост как три копейки и в охрениард раз меньше раста. С ядром справляется. Так что переставай брехать, и иди уже напиши чего-нибудь на своём расте.

Интересно, с закрытием USAID Rust Evangelism Task Force разбежится? А то задрали уже срать в камментах.

когда кстати компиляторы начнут понимать эмодзи? пора уже переходить к эмоционально-иероглифическому синтаксису языков программирования.

с закрытием USAID Rust Evangelism Task Force разбежится?

выйдет на лгбт протесты в составе колонн мексиканских иммигрантов.

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

последнего кто знал, что расположено за 16битной границей затоптал слон в какой-нить тайской провинции.

смайлики же, например этот 🤔

https://www.fileformat.info/info/unicode/char/1f914/index.htm

UTF-16 (hex) 0xD83E 0xDD14 (d83edd14)

Даже тут на LOR используется для реакций в тэге alt.

<img draggable="false" class="emoji" alt="🤔" src="https://cdnjs.cloudflare.com/ajax/libs/twemoji/14.0.2/72x72/1f914.png">

смайлики же, например этот 🤔

человечество и без него обойдется. в конце концов его можно в базовую кодовую страницу положить, ежли так надо.

Символы с 2048 по 65535 в utf-8 занимают 18 бит (3 байта по 8 бит).

Хм, а я думал что я считать не умею ;)

Хм, а я думал что я считать не умею ;)

Да, подвёл меня мозг. Хотя отчетливо помню как уверенно в голове крутилось именно 18.

это все из-за руста. у нас в деревне говорят - «в руст ушел, считай калека».

это все из-за руста.

Имеешь ввиду rust? Я так и не решился потратить время на его изучение. Для меня он будет больше мешать чем помогать.

Какие сисколы в ядерном коде?

Некорректный вывод. Главное требование к «безопасности» в сотовых телефонах - это огороженность модемной части, чтобы даже при большом желании юзер ее не заюзал как-нибудь не так, как хочется FCC и другим надзорам. Еще и чтобы даже в принципе не знал, что эта часть делает на самом деле.

Да, и это тоже. Хотя это ограничение уже бесполезно, потому что любой может купить bladeRF за 500 баксов и задрочить все окрестные базовые станции.

Linux в эту огороженность не вписывается уже только из-за своей лицензии. Его конечно научились тивоизировать и прикрывать, но все это не совсем то.

Тут ты сильно ошибаешься. Я видел как минимум один сотовый модем на линуксе. Так что его туда всунуть можно, просто очень гемморно из-за архитектуры этого самого люникса и не самой лучшей приспособленности к риалтайму. Проще взять что-то более подходящее, что все и делают. Так-то там обычный ARM.

На практике микроядра прошли для специализированных ОС. Я даже затрудняюсь сказать есть ли сейчас хоть сколько-то широко используемая универсальная ОС общего назначения на микроядре?

Потому что новых ОС общего назначения не выходило уже лет 30.

Даже MacOS давно гибридная и мало, чем от монолитной отличается. WinNT когда-то была как бы микроядерной, но еще в 90-х ее стали усиленно разбавлять, а сейчас Win10/11 язык не повернется назвать микроядерной.

Поправка: MacOS всегда была гибридом, ещё когда она была NeXT. WinNT тоже микроядром никогда не была, если мы говорим о публичных версиях. Что там было в Microsoft до NT 3.51, никто не знает. Причиной этому является достаточная убогость и недоработанность микроядер из 80х, в частности Mach, на котором основаны и MacOS, и даже HURD. С тех пор всё немного изменилось.

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

Нету у линукса микроядерных фич. Эти драйвера живут в пространстве ядра и при крахе тянут остальное ядро за собой. Другой вопрос, что линукс запускается процессом в составе микроядра через L4Linux и это даже используется.

То, что на настольных компах/серверах/ноутбуках список ОС не меняется уже 30 лет, совсем не означает что ничего нового или лучшего нельзя изобрести. Это просто означает, что для рисования Firefox и Word на экране этих ядер достаточно. Соответственно, микроядра используются там, где на них есть спрос, и это не запускалка для докера.

То, что на настольных компах/серверах/ноутбуках список ОС не меняется уже 30 лет, совсем не означает что ничего нового или лучшего нельзя изобрести.

Может хватит уже изобретать? Что бы распарсить страничку на сайте нужно 6 ядер и 16гб памяти :(