OS1: примитивное ядро на Rust для x86. Часть 2. VGA, GDT, IDT

[tongohiti]

Продолжайте, чёрт возьми! :)

[sickfar]

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

[MacIn]

и имеет размер 80*25 байт

Эм, 80*25*2 байт. Байт на символ и байт на атрибуты (цвет).

[sickfar]

Благодарю, поправил. Я использую структуру для символа, их как раз у меня 80*25, поэтому отложилось так :)

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub struct ColorCode(u8);

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
#[repr(C)]
struct ScreenChar {
    ascii_character: u8,
    color_code: ColorCode,
}

[MacIn]

outb(0x3D5, (position & 0xFF) as u8)

Интересно, а транслятор сможет это оптимизировать в
out dx, al
Без наложения маски и инлайном? Я не к тому, что это надо, просто интересно.

Сегменты и их типы (код, данные, трапы, гейты) должны быть описаны в глобальной дескрипторной таблице GDT, виртуальный адрес и размер которой загружается в регистр GDTR

Или в локальной LDT.
Если мы собираемся использовать не плоские глобальные сегменты, а выдавать каждой задаче свои, то места в GDT всем не хватит. Разместив дескрипторы в LDT (скажем, код-данные-стек-служебное что-то), мы займем в GDT только одну ячейку и 4 — в LDT данной задачи.

[sickfar]

Интересно, а транслятор сможет это оптимизировать

Думаю, что не сможет — я же не встраиваю ассемблер в rs-файлы и не пишу интринсики. Более того, у меня опасные ассемблерные методы обернуты в безопасные методы Rust, поэтому там на два вызова больше. А линкер скорее всего такой оптимизацией не занимается. Хотя как знать.

Или в локальной LDT.
Если мы собираемся использовать не плоские глобальные сегменты, а выдавать каждой задаче свои, то места в GDT всем не хватит. Разместив дескрипторы в LDT (скажем, код-данные-стек-служебное что-то), мы займем в GDT только одну ячейку и 4 — в LDT данной задачи.

Где-то я встречал утверждение, что современные компиляторы не могут в сегментную модель, только в плоскую. Я не берусь утверждать, что оно верное, но около 100% программ собираются под плоскую модель. Так что да, можно. Но я не увидел смысла. И даже можно было бы запускать плоские программы в сегментированной памяти — как вы описываете, выделяя по одному сегменту каждой задаче, но опять же — зачем, если никто так не делает, и пишут, что это устаревшая система.

[MacIn]

Просто отметил, что так тоже можно — при написании хоббийных ос бывают нестандартные ходы.

[AngReload]

const fn еще не в релизе

Так они уже стабильны, правда не очень много в с ними можно делать
https://blog.rust-lang.org/2019/02/28/Rust-1.33.0.html

[sickfar]

Похоже, я пропустил. Писал код когда еще не были стабильны. Надо освежить голову и пересмотреть код. Спасибо.

[VioletGiraffe]

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

А загрузка у вас через MBR? UEFI не изучали? Там всё совсем по-другому, и если материнка не поддерживает legacy BIOS режим, вы не сможете загрузиться.
P. S. Перечитал ещё раз первую статью (на этот раз — включив мозг), и понял, что эту работу за вас выполняет GRUB. Поправьте, пожалуйста, если всё равно неправильно понимаю.

[sickfar]

Да, все через GRUB. Начальная загрузка пока для меня выглядит сложной, так как я ещё не разобрался на приличном уровне с носителями и файловыми системами, чтобы корректно прочитать и загрузить образ. Думаю, что когда доберусь до реализации работы с HDD, можно будет и в сторону своего загрузчика посмотреть

[VioletGiraffe]

С MBR на удивление не сложно именно загрузиться, даже с флэшки. Заморочки, как я понял, только на флопиках были, там какая-то дополнительная структура нужна. Сложности и челленджи дальше с инициализацией защищённого режима, памяти и т. п.

[MacIn]

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

Везде одинаково: BIOS грузит нулевой сектор по 7c00h и передает туда управление. Все остальное — личное интимное дело конкретной системы.

[Zanak]

Решил просто сказать спасибо(плюсануть сейчас не могу, к сожалению). :)