Операционные системы с нуля; уровень 1 (старшая половина)24.03.2018 21:33

Что будет не так, если клиент сможет передавать произвольные состояния? [fake-states ]

Подумайте, что произойдёт, если мы позволим пользовательскому коду свободно выбирать начальное состояние для структуры Gpio. Что может пойти не так?

Почему это всё возможно только в Rust?

Обратите внимание на тот маленький факт, что into_-переходы используют семантику перемещения. Это означает, что как только Gpio переходит в другое состояние, то уже не может быть доступно в предыдущем состоянии. До тех пор, пока тип не реализует Clone, Copy и некоторые другие способы дублирования, обратный переход недоступен. Никакой другой язык так не умеет. Даже C++. Подобное колдунсво во время компеляции со всеми гарантиями есть только тут. (Гуру в плюсах или чём либо ещё могут попробовать оспорить это утверждение)

Реализация драйвера

Напишите весь необходимый код вместо unimplemented!() в файле pi/src/gpio.rs. Из комментариев и сигнатур всех этих методов можно понять при помощи дедукции их ожидаемую функциональность. Не лишним будет обратиться к документации (страница 89, раздел 6 из мануала по BCM2837). Не забудьте о полезности cargo check.

Подсказка: помните, что можно создавать произвольные лексические области видимости при помощи фигурных скобочек { ... }.

Тестирование драйвера

Очевидно, что для тестирования драйвера нам нужно написать немного кода в файлике kernel/src/kmain.rs.

На этот раз вместо чтения/записи непосредственно в сами регистры мы будем использовать наш драйвер для того, чтоб мигать светодиодиком. Посредством включения/выключения GPIO-пина номер 16. При этом всём код будет выглядеть намного чище и элегантнее. Скомпиляйте ядро, загрузите его на карточку под именем kernel8.img и запустите малинку с этим всем. Светодиод должен мигать абсолютно так же, как и ранее.

Теперь можно подключить побольше светодиодов. Используем контакты GPIO под номерами 5, 6, 13, 19 и 26. Обратитесь к диаграмме с нумерацией пинов из нулевой лабы, чтоб определить их физическое расположение. Пусть ядро мигает множеством светодиодиков так, как вы пожелаете!

Какой паттерн мигания вы выберали? [led-pattern]

По какой схеме вы решили включать/выключать светодиоды? Выбрать можно множество вариантов на свой вкус. Но если с выбором туго — можно включать и выключать их по кругу.

Как только ваш драйвер GPIO станет вполне себе рабочим — можно переходить к следующей подфазе.

Субфаза D: UART

В этой подфазе мы напишем драйвер устройства mini UART, который встроен в проц нашей малинки. Большинство работы выполняется в файлах os/pi/src/uart.rs и os/kernel/src/kmain.rs. Mini UART документирован на страницах 8 и 10 (разделы 2.1 и 2.2) манулала по BCM2837.

UART: Universal Asynchronous RX/TX

UART (ru) или Универсальный Синхронный ПриёмоПередатчик — это устройство и последовательный протокол для общения железок при помощи всего двух проводов. Это те самые два проводка (rx/tx), которые использовались в фазе 1 из нулевой лабы для того, чтоб подключить устройство UART на USB-модуле CP2102 к устройству UART на малинке. По UART можно отправлять любые данные: текст, двоичные файлы, картинки с котиками и на что там ещё фантазии хватит. В качестве примера прямо в следующей подфазе мы напишем интерактивную оболочку, которая будет читать с UART на малинке и писать в UART на CP2102. В фазе 4 мы будем передавать двоичную информацию примерно тем же самым способом.

У протокола UART есть несколько конфигурационных параметров. Как приёмник, так и передатчик должны быть настроены идентично для того, чтоб всё заработало. Вот такие эти параметры:

• Data Size — длинна одного кадра с данными (8 или 9 бит)
• Parity Bit — следует ли отправлять бит чётности (контрольный бит) после данных
• Stop Bits — сколько бит будем использовать для определения того, что данные переданы (1 или 2 бита)
• Baud Rate — скорость передачи в битах в секунду

Mini UART не поддерживает биты чётности и поддерживает только один стоповый бит. Таким образом нам требуется сконфигурировать только скорость передачи и длину кадра. Чуть подробнее про сам UART можно читнуть в документе под названием Basics of UART Communication (нуждается в переводе?).

Реализация драйвера

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

Задача состоит в том, чтоб реализовать всё необходимое в файлике pi/src/uart.rs. Потребуется дописать содержимое структуры Registers. При этом используйте вариант типа Volatile с минимально необходимым набором возможности для каждого регистра. Те регистры, которые доступны только для чтения должны использовать ReadVolatile. Если разрешена только записть, то WriteVolatile. Для зарезервированного пространсва есть Reserved. После этого всего допишите функцию new() и установите скорость 115200 (делитель 270) и длинну кадра данных в 8 бит. После всего замените все unimplemented!() на то, что там должно быть по смыслу. Ну и реализуйте трейты fmt::Write, io::Read и io::Write для типа MiniUart.

Подсказка: вам потребуется писать в регистры LCR, BAUD и CNTL для функции new/

Подсказка: используйте драйвер GPIO из прошлой подфазы.

Тестирование драйвера

Проверьте драйвер, написав код (в kernel/src/kmain.rs), который возвращает переданное обратно в неизменном виде. В псевдокоде это выглядит похожим на такое:

loop {
    write_byte(read_byte())
}

Используйте screen /dev/<имя_устройства> 115200 для связи по UART. screen отправит все нажатые кнопочки клавиатуры через TTY на малинку. Если всё правильно, то ещё и прочитает оттуда их же в неизменном виде. Т.е. вы увидите все набранные символы. Можно попробовать отправлять дополнительные парочку символов каждый раз при получении:

loop {
    write_byte(read_byte())
    write_str("<-")
}

Как только наш драйвер будет работать так, как от него ожидают — можно переходить к следующей подфазе.

Субфаза E: The Shell

В этой подфазе мы будем использовать наш свеженький драйвер UART для реализации простенькой оболочки к нашей операционной системе. Основная работа ведётся в файлах os/kernel/src/console.rs, os/kernel/src/shell.rsи os/kernel/src/kmain.rs.

Console

Для того, чтоб написать шелл, нам понадобится что-то похожее на глобальный ввод/вывод по умолчанию. Unix и его друзья с родсвенниками предоставляют программам stdin и stdout для подобных целей. Мы будем использовать Console для наших скромных нужд. Console позволит нам реализовать макросы kprint! и kprintln!. Оные будут делать примерно то же самое, что и print! и println!. Только на уровне ядра. Наши макросы будут использовать Console для того, чтоб делать своё чорное дело.

Взгляните на os/kernel/src/console.rs. Файлик содержит в себе недописанную реализацию структуры Console. По сути это синглтон-обвязка вокруг MiniUart. Только один экземпляр консольки сущесвует в нашем ядре. При этом он доступен везде и всегда. Это всё позволит нам взаимодействовать с MiniUart без явной передачи экземпляра MiniUart или экземпляра Console.

Глобальная изменяемость

Понятие глобальной изменяемой структуры — довольно страшная, грязная и противная мысль. Особенно в контексте Rust. В конце концов Rust не допускает более одной изменяемой ссылки на какое либо значение. Как нам убедить его в использовании такого количесва, в котором мы имеем потребность? Тут есть один трюк, который полагается на unsafe. Идея такая: мы говорим Rust’y, что будем только читать значения, т.е. использовать неизменяемую ссылку, но на самом деле мы будем небезопастно преобразовывать эту «неизменяемую» ссылку в изменяемую. Мы можем создавать столько неизменяемых ссылок, сколько захотим. Rust не будет бить по нашим ручкам и всё такое. Выглядеть подобное может примерно так:

// Эта функция никогда не должна существовать!
fn make_mut(value: &T) -> &mut T {
   unsafe { /* чорная магия и сильное колдунство */ }
}

Это очень и очень плохая идея. Такое предложение Очень Опасно. Нам всё равно нужно будет обеспечивать, чтоб всё, что делается в unsafe секции следовало правилам Rust. То, что мы предолжили только что явно не следует правилам. По меньшей мере правило «не более одной мутабельной ссылки за раз». Т.е. в любой точке программмы значение должно иметь не более одной изменяемой ссылки. И никак иначе.

Для того, чтоб соблюсти это правило нам нужно следующее. Вместо того, чтоб компилятор проверял за нас эту всю фигню с заимствованиями нам надо обеспечить проверку этого динамически во время выполнения проги. В результате мы можем делиться ссылками на такую структуру столько раз, сколько хотим (через &). Ну и безопастно извлекать изменяемую ссылку, когда она нам на самом деле требуется (&T -> &mut со всякими необходимыми проверками).

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

fn lock(value: &T) -> Locked<&mut T> {
   unsafe { lock(value); cast value to Locked<&mut T> }
}

impl Drop for Locked<&mut T> {
   fn drop(&mut self) { unlock(self.value) }
}

Эта штука называется Mutex и её можно найти в стандартной библиотеке. Другой способ — убивать программу, если будет создано более одной ссылки:

fn get_mut(value: &T) -> Mut<&mut T> {
   unsafe {
      if ref_count(value) != 0 { panic!() }
      ref_count(value) += 1;
      cast value to Mut<&mut T>
   }
}

impl Drop for Mut<&mut T> {
   fn drop(&mut self) { ref_count(value) -= 1; }
}

Суть та же, что у RefCell: borrow_mut (). Ну и ещё один вариант — вернуть мутабельную ссылочку только если известно, что она такая одна уникальная:

fn get_mut(value: &T) -> Option> {
   unsafe {
      if ref_count(value) != 0 { None }
      else {
         ref_count(value) += 1;
         Some(cast value to Mut<&mut T>)
      }
   }
}

impl Drop for Mut<&mut T> {
   fn drop(&mut self) { ref_count(value) -= 1; }
}

Это соотвественно RefCell: try_borrow_mut (). Это всё были примеры реализации различных форм «внутренней мутабельности»: они позволяют изменять неизменяемое. Для Console мы будем использовать Mutex. Поскольку для std::Mutex нам требуется поддержка со стороны операционной системы — у нас есть собсвенная реализация. С гейшами и го. Найти можно в файлике kernel/src/mutex.rs. На данный момент реализация вполне себе верная, но нам придётся подправить её, когда будем использовать кеширование или параллелизм, чтоб продолжать следовать правилам Rust. На данный момент нам не важны тонкости внутренностей Mutex, но важно понимать, как оно должно использоваться.

Итак. Глобальный синглтон объявлен как CONSOLE в kernel/src/console.rs. Эта глобальная переменная используется в макросах kprint! и kprintln!, определённых чуть ниже в файле. После того, как вы реализуете всё недостающее в Console — вы сможете эти самые макросы использовать для вывода информации через этот самый Console. Помимо этого можно использовать CONSOLE для глобального доступа к Console.

Rust помимо прочего также требует от статических глобальных переменных быть Sync.

Чтобы схоронить значение некого типа T в static переменной, этот тип T обязан реализовывать Sync. Это связано с тем, что Rust требует гарантий безопастности применительно к гонкам данных. Поскольку глобальные значения можно получать из любого потока, Rust должен гарантировать, что эти обращения потокобезопасны. Спецтрейты Send и Sync, также система владения Rust гарантируют отсутсвие гонок данных.

**Почему мы никогда не должны напрямую возвращать &mut T? [drop-container]

Как можно заметить, каждый предоставленный пример оборачивает изменяемую ссылку в контейнер, который реализует Drop. Что может пойти не так, если мы можем отдавать &mut T напрямую?

Куда идёт вызов write_fmt? [write-fmt]

Вспомогательная функция _print вызывает write_fmt у экземпляра MutexGuard (который пришел из Mutex::lock(). Какой тип имеет метод write_fmt и откуда берётся реализация этого метода?

Реализация и тестирование Console

Реализуйте всё, что должно быть на месте unimplemented!() в файлике kernel/src/console.rs. После этого попробуйте макросы kprint! и kprintln! в действии, написав немного кода в kernel/src/kmain.rs, который будет выводить что либо после того, как вы приняли какой либо символ. Эти макросы используются тем же самым образом, что и print! и println!. Используйте screen /dev/<имя-файла> 115200 для связи с малинкой.

Если бы мы писали на Няшном Си…

Мы получаем реализацию println! практически бесплатно и с нулевыми усилиями — ещё одно преимущество Rust. В Сишечке нам потребовалось бы самостоятельно реализовывать printf. В Rust нам предоставили общую, абстрактную, безопасную и независимую от ОС реализацию этого всего. Бонусом она ещё и быстрее работает. Неплохо, да? Я тоже так считаю.

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

Реализация оболочки

Теперь у нас есть абсолютно всё необходимое для реализации встроенной оболочки. Работаем в файле kernel/src/shell.rs. Там уже есть структура Command. Метод Command::parse() предоставляет простой синтаксический анализатор аргументов командной строки и возвращает структуру Command. По сути parse разбивает переданную строку на пробелы и сохраняет все непустые аргументы в поле args как StackVec, используя buf в качесве хранилища. При этом вы должны реализовать Command::path() самостоятельно.

Используйте все уже написанные библиотеки (Command, StackVec, Console через CONSOLE, kprint!, kprintln! и всё, что сочтёте нужным помимо этого) для реализации функции shell. Наша оболочка должна печатать содержимое prefix каждый раз, когда будет ожидаться ввод. В приведённой выше гифке в качестве префикса используется "> ". Затем оболочка должна прочитать строку ввода от пользователя, проанализировать её как команду и выполнить. Это всё должно делаться ad-infinitum. Мы только начали пилить нашу операционку и пока не можем запускать интересные команды. Однако мы можем создать простенкие команды вроде echo.

Для того, чтоб быть завершенной наша оболочка должна:

• реализовывать встроенную команду echo $a $b $c, которая должна напечатать $a $b $c
• принимать символы \r и \n как нажатия enter, отмечая конец строки
• принимать backspace и delete (ASCII 8 и 127) для удаления одного символа
• звонить в колокольчик (ASCII 7), если переданы не обрабатываемые невидимые символы
• выводить unknown command: $command для всех несуществующих $command
• не позволять стирать префикс
• не позволять вводить больше символом, чем разрешено
• принимать команды длинной до 512 байт
• принимать до 64 аргументов на команду
• начинать новую строку без всяких ошибок и уже с prefix, если пользователь ввёл пустую команду
• выводить error: too many arguments если передано слишком много аргументов

Протестируйте shell. Вызовите нашу функцию из kernel/src/kmain.rs. Если не считать баннера с SOS, то взаимодействие с оболочкой должно быть похоже на то, что на гифке. Кроме того вам надо проверить все требования, которые мы предоставили. Как только оболочка заработает — наслаждайтесь достижениями. Затем можно перейти к следующему этапу.

Подсказки:

Байтовый литерал b'a' имеет тип u8 и его код соответсвует символу 'a'

Используйте \u{b} в строковом литерале для печати любого символа с байтовым значением ASCII b

Вы должны вывести и \r и \n символы для перевода строки

Для того, чтоб стереть символ можно вывести backspace, затем пробел, затем снова backspace

Используйте StackVec для пользовательского ввода

Функция std: str: from_utf8 будет весьма и весьма полезна

Мы не используем реальный std!

Напомню, что мы используем кастомную пользовательскую реализацию std в нашем ядре. Реализация не полная. Для того, чтоб увидеть, что там есть можно выполнить xargo doc --open в директории os/std.

Как наша оболочка соединяет множество разных частей вместе? [shell-lookback]

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

Фаза 4: Загрузчик

В этой фазе мы до

© Habrahabr.ru