Comments 55
Основную работу делает rustc
. cargo
и xargo
— обёртки для управления зависимостями. Конкретно xargo
— временный костыль для управления кросскомпиляцией стандартной библиотеки Rust. Вполне возможно, что всё, что делает xargo
будет делать cargo
. По крайней мере работы по этой части ведутся.
cargo
и xargo
читают свои конфигурационные файлы, строят древа зависимостей одних компонентов от других. Потом они вызывают rustc
для каждого элемента этого древа в правильном порядке.
Compiling core v0.0.0 (file:///home/lain/.rustup/toolchains/nightly-2018-01-09-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore)
Running `rustc --crate-name core /home/lain/.rustup/toolchains/nightly-2018-01-09-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/lib.rs --crate-type lib --emit=dep-info,link -C opt-level=3 -C panic=abort -C debuginfo=2 -C metadata=a801d90a8ede2cec -C extra-filename=-a801d90a8ede2cec --out-dir /tmp/xargo.QYpehsg9dGcf/target/aarch64-elf/release/deps --target aarch64-elf -L dependency=/tmp/xargo.QYpehsg9dGcf/target/aarch64-elf/release/deps -L dependency=/tmp/xargo.QYpehsg9dGcf/target/release/deps --sysroot /home/lain/.xargo -Z force-unstable-if-unmarked`
Finished release [optimized + debuginfo] target(s) in 33.14 secs
+ RUSTFLAGS="--sysroot /home/lain/.xargo -Z force-unstable-if-unmarked"
+ "cargo" "build" "--release" "--manifest-path" "/tmp/xargo.DNOId6dEQEQf/Cargo.toml" "--target" "aarch64-elf" "-v" "-p" "compiler_builtins"
Compiling compiler_builtins v0.1.0 (file:///home/lain/.rustup/toolchains/nightly-2018-01-09-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcompiler_builtins)
Running `rustc --crate-name build_script_build /home/lain/.rustup/toolchains/nightly-2018-01-09-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcompiler_builtins/build.rs --crate-type bin --emit=dep-info,link -C opt-level=3 -C debuginfo=2 --cfg 'feature="compiler-builtins"' --cfg 'feature="default"' -C metadata=52e30c5973f6dcea -C extra-filename=-52e30c5973f6dcea --out-dir /tmp/xargo.DNOId6dEQEQf/target/release/build/compiler_builtins-52e30c5973f6dcea -L dependency=/tmp/xargo.DNOId6dEQEQf/target/release/deps`
Running `/tmp/xargo.DNOId6dEQEQf/target/release/build/compiler_builtins-52e30c5973f6dcea/build-script-build`
Running `rustc --crate-name compiler_builtins /home/lain/.rustup/toolchains/nightly-2018-01-09-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcompiler_builtins/src/lib.rs --crate-type lib --emit=dep-info,link -C opt-level=3 -C panic=abort -C debuginfo=2 --cfg 'feature="compiler-builtins"' --cfg 'feature="default"' -C metadata=bb86bee2bebfce0f -C extra-filename=-bb86bee2bebfce0f --out-dir /tmp/xargo.DNOId6dEQEQf/target/aarch64-elf/release/deps --target aarch64-elf -L dependency=/tmp/xargo.DNOId6dEQEQf/target/aarch64-elf/release/deps -L dependency=/tmp/xargo.DNOId6dEQEQf/target/release/deps --sysroot /home/lain/.xargo -Z force-unstable-if-unmarked`
Finished release [optimized + debuginfo] target(s) in 10.7 secs
+ RUSTFLAGS="--sysroot /home/lain/.xargo"
+ "cargo" "build" "--verbose" "--release" "--target=aarch64-elf"
Compiling blinky v0.1.0 (file:///home/lain/WORK/0-blinky/phase4)
Running `rustc --crate-name build_script_build build.rs --crate-type bin --emit=dep-info,link -C opt-level=3 -C debuginfo=2 -C metadata=38baa0b289c5375d -C extra-filename=-38baa0b289c5375d --out-dir /home/lain/WORK/0-blinky/phase4/target/release/build/blinky-38baa0b289c5375d -L dependency=/home/lain/WORK/0-blinky/phase4/target/release/deps`
Compiling rlibc v1.0.0
Running `rustc --crate-name rlibc /home/lain/.cargo/registry/src/github.com-1ecc6299db9ec823/rlibc-1.0.0/src/lib.rs --crate-type lib --emit=dep-info,link -C opt-level=3 -C panic=abort -C debuginfo=2 -C metadata=87e53cf10f387acb -C extra-filename=-87e53cf10f387acb --out-dir /home/lain/WORK/0-blinky/phase4/target/aarch64-elf/release/deps --target aarch64-elf -L dependency=/home/lain/WORK/0-blinky/phase4/target/aarch64-elf/release/deps -L dependency=/home/lain/WORK/0-blinky/phase4/target/release/deps --cap-lints allow --sysroot /home/lain/.xargo`
Running `/home/lain/WORK/0-blinky/phase4/target/release/build/blinky-38baa0b289c5375d/build-script-build`
Running `rustc --crate-name blinky src/lib.rs --crate-type staticlib --emit=dep-info,link -C opt-level=3 -C panic=abort -C lto -C debuginfo=2 -C metadata=5fdf374864fe84b4 -C extra-filename=-5fdf374864fe84b4 --out-dir /home/lain/WORK/0-blinky/phase4/target/aarch64-elf/release/deps --target aarch64-elf -L dependency=/home/lain/WORK/0-blinky/phase4/target/aarch64-elf/release/deps -L dependency=/home/lain/WORK/0-blinky/phase4/target/release/deps --extern rlibc=/home/lain/WORK/0-blinky/phase4/target/aarch64-elf/release/deps/librlibc-87e53cf10f387acb.rlib --sysroot /home/lain/.xargo`
Finished release [optimized + debuginfo] target(s) in 3.31 secs
Можно заметить, что опции из Cargo.toml
передаются ключами в rustc
.
Немного о внутренностях rustc
можно почитать например это https://rust-lang-nursery.github.io/rustc-guide/
rustc
в свою очередь берёт исходные файлы и преобразует их в тот вид, который его попросят. В нашем случае нам требуется статический файлик target/aarch64-elf/release/libblinky.a
. В нём содержится бинарный код и некоторая информация о том, как его можно будет потом использовать.
А использовать мы его будем самым гнустным образом. При помощи линкёра мы стыкуем его с crt0.o
(который получился из crt0.S
) и получаем build/blinky.elf
. Этого эльфа мы преобразуем в тот, формат, который будет потом читать загрузчик (по сути просто отрежем все заголовки elf-файла)
Я не всё детально расписал конечно, но самое основное.
Минуточку, если билдится blinky.elf, то кто со стороны малинки этот самый ELF парсит и грузит? Программировать под существующее линуксовое ядро — это не совсем "с нуля".
blinky.elf: $(BLINKY_OBJS) layout.ld
$(CROSS)-ld $(BLINKY_OBJS) -o $@ -Tlayout.ld
И crt0.S, который неявно подлинковывается к этому elf-у, как бы говорит нам о том, что это все будет запущено на малинке. Кто это там запускает?
Загрузчик. Точнее их целых два. bootcode.bin и start.elf.
В следующей части мы свой загрузчик напишем. Наш загрузчик будет подгружать ядро по UART.
А кто подгружает наши загрузчики? Хороший вопрос. Этим занимается прошивка, до которой нам будет сложновато добраться (там закрыто и опечатано всё). По сути эта прошивка занимается примерно тем же, чем такая же штука в ардуинке — даёт нам возможность не использовать всякую тяжелую обвязку с программаторами и прочим.
Тут стоит немного упомянуть о том, что предоставляет нам процессор по части защиты одних частей от других.

Есть обычный мир и защищённый мир. В рамках курса мы будем воплощать наши хитрые планы в обычном мире.
Код, который мы выполняем по ходу курса будет выполняться на уровне Гипервизора. Чуть позже будет рассказано, как перемещаться с EL2 до EL1 и до EL0. И обратно. Понадобится нам это не раньше, чем будем работать с программами/потоками/процессами. Хотя может я напишу что-то про ассемблер и вот такое всё, применительно к этой архитектуре. Я не буду ограничиваться просто переводом оригинального курса. Иначе это было бы слишком скучно. (Тут стоит заметить, что я сам всё это потихоньку изучаю).
Неясен смысл установки nightly-версии Rust. Что такого в ней появилось, чего ещё нет в stable? Не помешала бы об этом пара слов. Поскольку ночные сборки у каждого (скорее всего) будут свои, то не мешало бы понимать, для чего они вообще (может, скоро необходимые возможности в stable переберутся и ночные сборки станут не нужны).
Аналогичный вопрос про xargo. Зачем он нужен? Можно ли всё сделать силами одного лишь cargo или это невозможно и xargo делает некую магию? Это тоже хотелось бы понимать.
Нам нужно компилировать стандартные библиотеки, а не использовать свои готовые. Их можно скомпилировать только ночной сборкой компилятора.
Почему готовые нельзя использовать? Rasperry Pi недостаточно популярная архитектура и под неё нет готовых собранных пакетов или причина в чём-то другом?
Проще предоставить возможность скомпилировать это всё для страждущих, чем предоставить хотелки на каждый чих. Кроме того можно собственную модифицированную версию туда влепить. Скажем использовать штуки из стандартной библиотеки (из std::io например) там, где у нас не заработают другие части (например std::net). Мы можем просто скопировать код стандартной библиотеки и вырезать то, что работать не будет.
Собственно основное назначение стандартной библиотеки — взаимодействие с операционной системой.
Помимо стандартной библиотеки там есть чуть более мелкие библиотеки вроде core и прочих. Зачем нам может понадобиться их компилять? Мы можем использовать разные опции компилятора для наших нужд. Например нужно ли нам использовать SIMD (на арме это NEON) или нинужно. Или ещё что-то. На все комбинации всех опций бинарники не предоставишь (технически можно, но ненужно ибо их будет очень много).
Собственно это всё есть в готовом виде для самых самых распространённых платформ. Под платформой будет подразумеваться Target Triplet. Т.е. сочетание процессора/окружения/операционной системы/чего там ещё. В нашем конкретном случае это что-то вроде aarch64-none-elf или что-то похожее. Т.е. проц с архитектурой aarch64, отсутствие ОСи и немного сочного мяса эльфов.
Это основная киллерфича Rust на мой взгляд. Лучше, чем во вполне оффициальной книге я рассказать врятли смогу. https://doc.rust-lang.org/book/second-edition/
Если касательно программирования, то начинать стоит с книжечки по Rust. На русском последняя версия всё ещё не опубликована, но можно потыкать прямо вот тут: https://github.com/ruRust/rust_book_2ed/tree/ru_version/second-edition/src
По линуксу и вообще командной стоке можно много чего почитать. https://ryanstutorials.net/linuxtutorial/ https://ru.hexlet.io/courses/bash в качестве первых попавшихся примеров. Даже списком https://proglib.io/p/10-linux-resources/ Гугл по запросу "linux туториал" выдаст достаточно интересного на любой вкус. В том числе и в виде видях на ютубчике.
А так — спрашивайте конкретные вопросы. Каждый подразумевает под нулевым уровнем что-то своё.
Язык проблем не представляет при этом, могу изучать английские материалы.
отсутствие опыта работы с компилируемыми языками, за исключением ВУЗовской начальной программы по C.
И этого опыта должно быть в целом достаточно. Предполагается, что Rust изучается по ходу курса.
Отсутствие опыта работы с электроникой, схемами, понимания их устройства.
В рамках этого курса достаточно самых самых минимальных знаний. По железной части кроме светодиодиков чего-то особого не будет (как работает UART, будет объяснено). Если есть желание фундаментально углубиться в эту тему, то есть лютейшая годнота под названием The Art of Electronics. Раз нет проблем с изучением англоязычных материалов — берите третье издание на английском (на русском совершенно другая нумерация и 3, 4, 5 и т.д. будут относится ко второму изданию на самом деле).
Почти полное отсутствие представлений об устройстве операционной системы.
В рамках курса исправим. С точки зрения практики, а не теории. После некоторой практики в рамках курса теорию будет гораздо интереснее и понятнее изучать кстати. Из самого близкого к оригиналу есть лекции https://web.stanford.edu/~ouster/cgi-bin/cs140-spring14/lectures.php которые в свою очередь рекомендуют читать книжечку Operating Systems: Principles and Practice.
У меня приятель в школьные годы на ASM трехзадачную ОС написал… вот это даже "-3" этаж.
Продолжая аналогию, цель курса не в умении работать лопатой ниже уровня моря, а в умении построить дом от подвала до верхнего этажа. И да, мы будем пользоваться лифтом.
Меня никогда не тянуло на низкоуровневый кодинг. Что до лифта, то "с нуля" надо в кавычках тогда писать, с "нуля"
.
У меня есть такое ИМХО, что для обучения студентов или увлечённых старшешкольников основам ОС в настоящее время требуется не только демонстрационная-учебная ОС типа «Minix» и подобных, но и учебное «железо» с минимальным набором устройств и интерфейсов (в пределах разумного). Потому что для учёбы даже нынешние одноплатники уже слишком сложны и перегружены всякими расширениями. Минимальным джентельменским набором я считаю такой список: SPI, SDIO, 2xUART, 2xUSB (можно только хост), GPIO (физически отдельно от обоих UART), JTAG. Вместо SPI Flash с u-boot — слот под microSD-карту. SDIO — на слот под полноразмерную SD. И дисплей 800x480 на борту, также работающий по SPI.
Или в плане программы курса предусмотрено демонстрационное простейшее ядро с планировщиком, где каждый отдельный процесс моргает собственным светодиодом?
Предусмотрено. Правда ближе к концу оригинального курса. Не хочется сразу пугать размером мануала на ARMv8.
Про фреймбуфер (и ускорение видео!) и usb я попробую отдельно рассказать. Может быть и про SDIO, но мне бы самому во всём этом разобраться. Про отдельный экранчик тоже расскажу, когда руки дойдут.
Суть такова:
Уровень 0: Hello World
Уровень 1: Uart, чуть более удобный бутлоадер
Уровень 2: Работа с памятью и немного с файловой системой
Уровень 3: Асм и процессы
При этом на уровне 0 предполагается, что человек уже умеет на чём-то прогать из Си-подобного и в состоянии установить линупс при помощи гугла. Всё остальное явно или неявно познаётся в процессе.
После основного курса можно будет пилить различные дополнения. Благо периферии там много разной.
Вообще лихо они запитали RPi 3 от USB компа по ардуиновски. По спеку USB 500mA, малина
Boot Max 0.75A
Idle Avg 0.30A
хотя если периферия не подключена то может и потянуть.
Ну и соответственно внешнего блока питания подключать ка малине не надо если делать как описано, а если подключать, то тогда не подключать +5V с CP2102 — питание все же должно быть одно по правилам. Хотя… малинщики сами признают что бывает poweer backfeed из активных USV хабов и не всегда все сгорает.
А клоны малины пойдут для этого дела?
Там обязателен проц BCM2837. Соответственно это должен быть точный клон определённой версии малинки. Что на али, что на амазоне — малинка стоит примерно $38 (около 2200 рублей). Не то, чтоб дорого с учётом бесплатной доставки. Лично я с амазона заказал. Дополнительные плюшки мне вдвое дороже вышли, лол.
Кого? Набор? electronics kit raspberry pi
в поиске по магазину. Выбрать можно по вкусу. Светодиоды и резисторы есть практически в любом. Удобные коробочки может и не во всех есть, но там по фотографиям будет понятно. У меня конкретно этот, но я таки рекомендую повыбирать что-то самостоятельно.
Если кому-то интересно, могу описать процесс сборки.
[quote]Затем вставляем карточку в малинку и подключаем малинку к питанию. [/quote]
Наверное, стоило бы отметить, что подключаем питание желательно не к usb компьютера, а так же подключаем usb-uart конвертор в usb?
Серьёзные настольные ОС пишутся под несколько другие архитектуры. Потом, не очень понятен упор на аппаратную часть:
В уровне 3 это будет на столько критично, что чуть ли не с нуля придётся переписывать. Асм-часть точно будет другой.
Разве в ОС главное не общие принципы (планировщик, файловая система, всё что выше вы писали)? Эти вещи вроде обычно на C реализуют, а не на ассемблере.
Если суть использования Малины в том, что это единственное железо, с которым реально поэкспериментировать руками каждому — тогда у меня вопрос, почему под Intel x86/x64 таких штук не выпускают.
Серьёзные настольные ОС пишутся под несколько другие архитектуры.
Есть мнение, что таких архитектур примерно три. У нас одна из них. ARM — это по меньшей мере все современные смартфоны. И я не знаю, считаете ли вы Android (например) серьёзной операционной системой. Есть правда забавная деталь. ARMv8 (с нашим AArch64 в нашем проце) вышел в 2011 году, а первый чип в 2012. По меркам популярных архитектур это совсем недавно. Буквально утром за завтраком было.
Проще архитектура?
Сложность amd64 и этого всего в большом количестве легаси (см. x86). У арма сложность не в нём самом (не то, чтоб там было всё совсем просто), а в том, что с периферией от чипа к чипу та же беда, что и в вебе с фреймворками. Это если обобщать.
Разве в ОС главное не общие принципы (планировщик, файловая система, всё что выше вы писали)? Эти вещи вроде обычно на C реализуют, а не на ассемблере.
Есть буквально парочка штук, которые можно реализовать ТОЛЬКО на ассемблере. 150-200 строк на асме это немного (примерно такой размер для третьей части у init.S
). Но достаточно для того, чтоб об этом стоило бы поговорить. Если уж мы вскрываем эту тему, то стоит углубиться дальше, чем комментирование этого самого init.S
. Кроме того есть ещё парочка штук, которые без знания грязных подробностей работы современных процессоров сложновато объяснить.
тогда у меня вопрос, почему под Intel x86/x64 таких штук не выпускают
Выпускают. У вас на столе лежит одна такая. Можете попробовать. Благо инфы на эту тему огромное количество. Даже на русском языке. Если хочется прям всенепременно одноплатник, то что-то вроде есть в этом маленьком списке. Буквально десяток таких платок или около того.
А вообще может вам немного не совсем понятна цель курса? Цель стоит не научиться взаимодействовать с существующими ОС (через понимание их устройства), а именно то самое. Драйвера допустим писать. Может быть под чуть более экзотическую архитектуру что-то настрочить.
Одна такая экзотическая примочка поставляется вместе с малинкой. Про это будет в моём сочинении на тему "как я провёл лето".
Только я этого не говорил. Сообщаю это исключительно на случай ежели лето будет достаточно тёплым для сочетания гавайской рубашки и характерного головного убора в красно-белых тонах. Мне самому ещё предстоит разобраться в этом.
Курс одной ногой в OSdev, а другой в embedded. Утрируя: чуть влево — Таненбаум с косой стоит, чуть в право — Свидетели Arduino с мигающими светодиодами вместо глаз. По центру камень. Гранитный. Можно погрызть чуток. Или лизнуть хотяб.
И я не знаю, считаете ли вы Android (например) серьёзной операционной системой.
Серьёзной, да, настольной — сорри, но нет (моё мнение).
Сложность amd64 и этого всего в большом количестве легаси (см. x86)
Что плохого в легаси? В том, что его много, и долго про него писать?
Кроме того есть ещё парочка штук, которые без знания грязных подробностей работы современных процессоров сложновато объяснить.
Я не против знать «грязные» подробности работы процов, это интересно и полезно. Но изучать весь ASM во всём объёме, да ещё и с практикой? Это тяжко слегка) Или там и не будет такого?
У вас на столе лежит одна такая.
Вы сейчас про что? Про клаву с её прошивкой?)
… а именно то самое. Драйвера допустим писать. Может быть под чуть более экзотическую архитектуру что-то настрочить.
Так мелко? :D Я-то думал, написать свою ОС. Шутка. А если серьёзно — то иметь для работы над такой ОС хотя бы начальную теоретическую базу (и кстати да, несколько неплохих примеров систем, созданных небольшими коллективами, есть на слуху, одна даже чуть ли не на модифицированном NT ядре сделана).
Серьёзной, да, настольной — сорри, но нет (моё мнение).
Я к тому, что настольные операционки это меньшая часть этой области. Есть ещё мобилки, серваки, суперкомпьютеры и целый ворох всякого встроенного от роутеров с розетками до станков с ракетами. Все эти симкарты, жесткие диски и SSD...
Что плохого в легаси? В том, что его много, и долго про него писать?
Там дофига всяких неприятных штук вроде странных режимов работы процессора. Проблема в том, что эти режимы реально приходится использовать. Например если нам нужна графика.
Да и набор команд выглядит достаточно непродуманным. Это же просто наслоение костылей из разных эпох. Я не говорю, что это прям плохо. Но рассказывать про это будет гораздо дольше.
Но изучать весь ASM во всём объёме, да ещё и с практикой?
А в чём проблема? Там нет многотонного легаси. Оно спроектировано достаточно лёгким и понятным. Там будет всё, что можно назвать основами. Т.е. все основные команды над основными регистрами. Чуточку специальных штук. Ну и прерывания. Т.к. это RISC — основных команд там не то, чтоб много. Можно даже запомнить их. В отличии от.
Вы сейчас про что? Про клаву с её прошивкой?)
Про ту коробочку, которая PC. Вполне себе коробочка с процем, поддерживающем amd64.
А если серьёзно — то иметь для работы над такой ОС хотя бы начальную теоретическую базу
А как на счёт познавания этой самой базы в процессе или после этого всего, но по горячим следам? Всмысле сначала разбираемся с минимумом. Ну чтоб работало. А потом нам приходит светлая мысль: а как это можно улучшить, чем дополнить и т.д.?
и кстати да, несколько неплохих примеров систем, созданных небольшими коллективами, есть на слуху, одна даже чуть ли не на модифицированном NT ядре сделана
Не знаю такой. Если вы про ReactOS, то никакого отношения к NT она не имеет. Там полностью свободное ядро. Алсо этот проект не является хорошим годным примером, как проектировать ОС с нуля во имя учебных целей. Там задачи немного другие.
Если вы про ReactOS, то никакого отношения к NT она не имеет. Там полностью свободное ядро.
Ну я где-то читал, что там до кучи от NT 5.x, если ничего не путаю. Или реализовано по мотивам (код того ядра уже открыт), или прямо взято оттуда. А какие там задачи?
Вполне себе коробочка с процем, поддерживающем amd64.
amd64 — это то же самое, что x64? Сорри за глупый вопрос.
И если про PC — то не на столе, а под столом, у меня не ноут :)
А в чём проблема? Там нет многотонного легаси. Оно спроектировано достаточно лёгким и понятным.
Стоп, я начинаю путаться. Значит, про странные режимы работы и костыли рассказывать долго, а про ASM — быстро? Но ведь ASM — это те же машинные коды, только в буквенном, человекочитаемом виде. Смысл операций (во всяком случае простых) там совершенно аналогичен. И мне ассемблер простым не кажется… Пытался уже изучать немного, когда надо было в IDA Pro с отладкой одной софтины возиться :)
Ну я где-то читал, что там до кучи от NT 5.x, если ничего не путаю.
Нет. Это полностью свободное ядро. Оно скорее по мотивам. Точнее даже по слухам. Но точно не на основе. Там нет и не может быть несвободного кода.
amd64 — это то же самое, что x64?
Абсолютно то же самое. Его ещё x86_64 называют. И все эти названия взаимозаменяемые.
Значит, про странные режимы работы и костыли рассказывать долго, а про ASM — быстро?
В рамках курса нам достаточно подмножества асма. Количество команд, сравнимое с количеством пальцев. Этих команд нам уже будет достаточно для понимания сути этого всего. Доступ к памяти, простая арифметика, перемещение данных в регистры (mov) и ветвление. Всё остальное — суть вариации над этим (и парочка спец-команд для сильного колдунства, которые будут объяснены тогда, когда реально потребуются). Если эти концепции усвоить, то остальные команды можно изучить самостоятельно (по мере потребности в них). Там документация такая, что по ней можно свой процессор собрать (точнее ей действительно так пользуются). В плане структурированности — настоящее гикпорно.
Операционные системы с нуля; Уровень 0