
Комментарии 13
Двумя руками поддерживаю: статья/карма/подписка +/+/+.
Дружеский совет: уходите с rust в POD на С++98 пока не поздно. Потом - не выберетесь. Если чо - могу дровишек подбросить. (Есть скромное мнение и по GUI и по многому из того, что у вас запланировано.) :)
Тем более:
C 66.0%
Rust 30.5%
Assembly 1.1%
C++98?! Совет точно дружеский?
Более чем. С учётом того, кто организовал травлю С/С++ и как "продвигает" Питушманыч с Растом. Спойлер: CISA, АНБ (NSA), ФБР (FBI).
Глубоко не убеждён ни в продвигаемых этими организациями "инициативах", ни в методах их "продвижения", ни в их "гарантиях" и бережной заботе о "конечном потребителе".
Хронология "продвижения" здесь: https://habr.com/ru/articles/1029848/comments/#comment_30028238
( Warning! "Нейрослоп", эпилептикам и гражданам со слабой психикой ссылку не открывать. )
PS Вообще никого не удивляет, что "вдруг" начавшийся в СМИ психоз в отношении С/С++ граничит с психозом 2019-го вокруг COVID? :)
А почему? Мне кажется это из серии вредных советов 8) Наверное в C++98 все более предсказуемо, потому что есть только указатели и железо, но в расте компилятор ловит состояние гонки и ошибки памяти за вас. Искать баги неделями, ну такое себе, имхо, лучше обнаруживать на этапе компиляции, все, что можно, и то, это не гарантия. Я только начал изучать раст, для себя, с++ изучал только в институте, лет 20 назад. Насколько я понимаю, способов выстрелить себе в ногу в расте на порядок меньше, для того он и создан. Думаю не стоит бояться нового, тем более если у нового есть хорошие плюшки, хотя конечно, инструмент выбирается под задачи. Но насколько я помню раст уже в ядре линукса присутствует и его доля будет увеличиваться.
Спасибо за отклик! Проекты вроде CactOS — это отличная площадка для экспериментов, поэтому и получился такой гибрид Си и Rust (последний здорово спасает от глупых багов памяти).
Предложение по GUI очень актуально: я как раз начал писать композитор для графической подсистемы. С удовольствием посмотрю на ваши исходники и идеи, обмен опытом сейчас будет супер полезен!
Красивое
Технологические решения хорошо расписаны, выглядят как обоснованные
Я так понял, ядро Rust, многозадачность. Сетевая часть и файловые системы взято что-то готовое на Си. Разумно...
Впрочем, я не настоящий сварщик©
Спасибо! Проект действительно собирался как конструктор из лучших доступных элементов, чтобы не изобретать велосипеды там, где это не нужно.
Сейчас этот гибрид Си и Rust проходит проверку на прочность — я как раз начал писать графический композитор для GUI и портировал TCC. Надеюсь, в следующей статье архитектура покажет себя так же обоснованно!
Непонятно только зачем вы используете устаревшие MTRR для WC burst mode'а и так ограниченные до 8 регистров в ядре со страничной адресацией, это времена когда на пейдж атрибуты выделяли 2 бита а не 3 без extended'а, caching mode можно настраивать через слоты в MSR регистре IA32_CR_PAT (0x277), и так и топологически вернее: MTRR для физ адресов / физ адресов но поверх виртуальных, а MSR сугубо для виртуальных, топология virt on phy.
Вспоминается еще UC- для обработной совместимости.
Да, абсолютно согласен насчет PAT и MSR 0x277. Использование MTRR здесь — это осознанный временный костыль для быстрого старта прототипа. Мне нужно было гарантированно завести burst mode на реальном железе — стареньком ноутбуке с процессором AMD R425, на котором я все тестировал. Вообще, чтобы быстрее выкатить рабочую версию ядра, я использовал много легаси-решений. На материнской плате до сих пор висят старые контроллеры по типу PIT, PIC/IRQ и древняя конфигурация PCI, которые я тоже планирую переписать в рамках перехода на современную архитектуру APIC/MSI-X. Просто эти задачи пока сдвинуты на второй план и выполнять их сейчас нецелесообразно.
Что вы несете? MSR слоты для caching mode'а появились еще в 3 пентиуме в 1999 году, а ваш ноут явно не времен 90'ых, вы это оправдываете как "временный костыль, гарантированно завести на моем стареньком ноуте", какие боже распаенные PIC, PIT контроллеры в ноуте 2010 года... Они были во временах 8086-80386 позже внедрены в кристал. APIC/MSIX на Легаси? Что?
Если говорить прямо, выбор MTRR, а также использование интегрированных в южный мост эмуляций PIT и PIC(да я не верно выразился про то что они впаяны, когда их давно нет) — это результат того, что база ядра собиралась по классическим OSDev-материалам на этапе раннего прототипирования. Система успешно завелась на тестовом железе в такой конфигурации, и приоритеты сместились на другие задачи. Переход на PCIe, ACPI/MCFG, APIC и табличный PAT — это очевидный технический долг, который зафиксирован в планах по развитию ядра, но на данном этапе эти задачи были отложены как нецелесообразные для релиза графического стека. А в случае ноутбука это все обратно совместимо. Именно по этому я оставил так как есть, можно сказать в "долгий ящик". На самом деле, проект разросся в настоящую махину, и одному тащить всё железо и графику дальше тяжело. Раз вы настолько глубоко знаете матчасть и спецификации x86 — прошу помощи с этими задачами.(если конечно не трудно :) )
На современной MSR топологии PAT реализовать гораздо легче, и занимает почти в 2 раза меньше строк кода, чем на устаревшой MTRR топологии, выбор изначально нерационален и бессмысленен, вы не во временах 95 винды ядро пишете
CactOS