Комментарии 55
НЛО прилетело и опубликовало эту надпись здесь

Спрашивайте, что не понятно. Это как раз тот случай, когда "глупые" вопросы только приветствуются.

Используя доку по BCM2835, возможно повторить это на Raspberry Pi Model B? На новенькой третьей не хочется экспериментировать пока.
//Спасибо за актуальную, интересную статью.
Надо-бы пояснить как с помощью rust & xargo собирается кросс-платформенный бинарник.
НЛО прилетело и опубликовало эту надпись здесь

Основную работу делает rustc. cargo и xargo — обёртки для управления зависимостями. Конкретно xargo — временный костыль для управления кросскомпиляцией стандартной библиотеки Rust. Вполне возможно, что всё, что делает xargo будет делать cargo. По крайней мере работы по этой части ведутся.


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


Если добавить флаг --verbose
   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 парсит и грузит? Программировать под существующее линуксовое ядро — это не совсем "с нуля".

А кто тут elf собирает? Я вижу bin, который загружают bootcode.bin, config.txt и start.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. И обратно. Понадобится нам это не раньше, чем будем работать с программами/потоками/процессами. Хотя может я напишу что-то про ассемблер и вот такое всё, применительно к этой архитектуре. Я не буду ограничиваться просто переводом оригинального курса. Иначе это было бы слишком скучно. (Тут стоит заметить, что я сам всё это потихоньку изучаю).

Выполнять свой код на EL3 возможно или все так же анально огорожено, как у Интела?

Неясен смысл установки nightly-версии Rust. Что такого в ней появилось, чего ещё нет в stable? Не помешала бы об этом пара слов. Поскольку ночные сборки у каждого (скорее всего) будут свои, то не мешало бы понимать, для чего они вообще (может, скоро необходимые возможности в stable переберутся и ночные сборки станут не нужны).


Аналогичный вопрос про xargo. Зачем он нужен? Можно ли всё сделать силами одного лишь cargo или это невозможно и xargo делает некую магию? Это тоже хотелось бы понимать.

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

Почему готовые нельзя использовать? Rasperry Pi недостаточно популярная архитектура и под неё нет готовых собранных пакетов или причина в чём-то другом?

Проще предоставить возможность скомпилировать это всё для страждущих, чем предоставить хотелки на каждый чих. Кроме того можно собственную модифицированную версию туда влепить. Скажем использовать штуки из стандартной библиотеки (из std::io например) там, где у нас не заработают другие части (например std::net). Мы можем просто скопировать код стандартной библиотеки и вырезать то, что работать не будет.


Собственно основное назначение стандартной библиотеки — взаимодействие с операционной системой.


Помимо стандартной библиотеки там есть чуть более мелкие библиотеки вроде core и прочих. Зачем нам может понадобиться их компилять? Мы можем использовать разные опции компилятора для наших нужд. Например нужно ли нам использовать SIMD (на арме это NEON) или нинужно. Или ещё что-то. На все комбинации всех опций бинарники не предоставишь (технически можно, но ненужно ибо их будет очень много).


Собственно это всё есть в готовом виде для самых самых распространённых платформ. Под платформой будет подразумеваться Target Triplet. Т.е. сочетание процессора/окружения/операционной системы/чего там ещё. В нашем конкретном случае это что-то вроде aarch64-none-elf или что-то похожее. Т.е. проц с архитектурой aarch64, отсутствие ОСи и немного сочного мяса эльфов.

Да и к этому нужно упорно приложить руку тогда и все работает…
А какими учебными материалами лучше эти лабораторные работы сопроводить для человека, у которого тот самый уровень 0?

Если касательно программирования, то начинать стоит с книжечки по 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. Отсутствие опыта работы с электроникой, схемами, понимания их устройства. Мизерные навыки работы с командной строкой. Почти полное отсутствие представлений об устройстве операционной системы.
Язык проблем не представляет при этом, могу изучать английские материалы.
отсутствие опыта работы с компилируемыми языками, за исключением ВУЗовской начальной программы по 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" этаж.

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

Меня никогда не тянуло на низкоуровневый кодинг. Что до лифта, то "с нуля" надо в кавычках тогда писать, с "нуля".

Только это больше похоже не на «Операционные системы с нуля», а «Спортивный ардуининг на Малинке-3 с нуля». Или в плане программы курса предусмотрено демонстрационное простейшее ядро с планировщиком, где каждый отдельный процесс моргает собственным светодиодом?

У меня есть такое ИМХО, что для обучения студентов или увлечённых старшешкольников основам ОС в настоящее время требуется не только демонстрационная-учебная ОС типа «Minix» и подобных, но и учебное «железо» с минимальным набором устройств и интерфейсов (в пределах разумного). Потому что для учёбы даже нынешние одноплатники уже слишком сложны и перегружены всякими расширениями. Минимальным джентельменским набором я считаю такой список: SPI, SDIO, 2xUART, 2xUSB (можно только хост), GPIO (физически отдельно от обоих UART), JTAG. Вместо SPI Flash с u-boot — слот под microSD-карту. SDIO — на слот под полноразмерную SD. И дисплей 800x480 на борту, также работающий по SPI.
Или в плане программы курса предусмотрено демонстрационное простейшее ядро с планировщиком, где каждый отдельный процесс моргает собственным светодиодом?

Предусмотрено. Правда ближе к концу оригинального курса. Не хочется сразу пугать размером мануала на ARMv8.


Про фреймбуфер (и ускорение видео!) и usb я попробую отдельно рассказать. Может быть и про SDIO, но мне бы самому во всём этом разобраться. Про отдельный экранчик тоже расскажу, когда руки дойдут.

Если кто-то заинтересовался такой вещью как написание своей ОС, то предполагается, что с ассемблером он(а) уже достаточно хорошо знаком(а), и этот мануал уже как минимум прочитан «по диагонали». А вообще, перед тем, как программировать драйверы шин и прочие бэкенды, надо бы сделать акцент на базовых деталях — взаимодействие ядра и планировщика, что такое системные вызовы и для чего нужны, какие примитивы реализует libc, взаимодействие процесса пользователя с планировщиком и ядром, запуск и завершение процесса.

Суть такова:


Уровень 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 в поиске по магазину. Выбрать можно по вкусу. Светодиоды и резисторы есть практически в любом. Удобные коробочки может и не во всех есть, но там по фотографиям будет понятно. У меня конкретно этот, но я таки рекомендую повыбирать что-то самостоятельно.

В принципе, stage4 я собрал под Orange PI PC (код мигания светодиодами из stage4/src/lib.rs пришлось переписать полностью, т.к. другая SoC). Имею ввиду, что код rust без особых проблем можно скомпилировать и под orange pi. Другое дело, что архитектурно-зависимый код курса придется переписывать под свою платформу.

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

Собственно это решает. В уровне 3 это будет на столько критично, что чуть ли не с нуля придётся переписывать. Асм-часть точно будет другой.

[quote]Затем вставляем карточку в малинку и подключаем малинку к питанию. [/quote]
Наверное, стоило бы отметить, что подключаем питание желательно не к usb компьютера, а так же подключаем usb-uart конвертор в usb?

А в чём прикол изучения именно на основе ARM и Raspberri Pi? Проще архитектура?
Серьёзные настольные ОС пишутся под несколько другие архитектуры. Потом, не очень понятен упор на аппаратную часть:
В уровне 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, так что называть его не имеющим отношения весьма странно.
Я тоже не совсем понял, о чём писал предыдущий оратор, но парочка студенческих проектов на основе ядра WRK вполне существует. Правда проектов, зашедших дальше замены алгоритма деревьев на RB-Tree в дальнем уголке ядра от наших китайских друзей, я не встречал.
Если вы про ReactOS, то никакого отношения к NT она не имеет. Там полностью свободное ядро.

Ну я где-то читал, что там до кучи от NT 5.x, если ничего не путаю. Или реализовано по мотивам (код того ядра уже открыт), или прямо взято оттуда. А какие там задачи?

Вполне себе коробочка с процем, поддерживающем amd64.

amd64 — это то же самое, что x64? Сорри за глупый вопрос.
И если про PC — то не на столе, а под столом, у меня не ноут :)

А в чём проблема? Там нет многотонного легаси. Оно спроектировано достаточно лёгким и понятным.

Стоп, я начинаю путаться. Значит, про странные режимы работы и костыли рассказывать долго, а про ASM — быстро? Но ведь ASM — это те же машинные коды, только в буквенном, человекочитаемом виде. Смысл операций (во всяком случае простых) там совершенно аналогичен. И мне ассемблер простым не кажется… Пытался уже изучать немного, когда надо было в IDA Pro с отладкой одной софтины возиться :)
Ну я где-то читал, что там до кучи от NT 5.x, если ничего не путаю.

Только идеи и интерфейсы.
Или реализовано по мотивам (код того ядра уже открыт), или прямо взято оттуда.

Не взято ни строчки. Ну или по крайней мере уличить их в краже нельзя.
Код ядра не открыт, там такая лицензия, что разработчикам ReactOS дышать в их сторону нельзя.
amd64 — это то же самое, что x64? Сорри за глупый вопрос.

Естественно. Спасибо AMD за ещё один слой костылей поверх x86.
Ну я где-то читал, что там до кучи от NT 5.x, если ничего не путаю.

Нет. Это полностью свободное ядро. Оно скорее по мотивам. Точнее даже по слухам. Но точно не на основе. Там нет и не может быть несвободного кода.


amd64 — это то же самое, что x64?

Абсолютно то же самое. Его ещё x86_64 называют. И все эти названия взаимозаменяемые.


Значит, про странные режимы работы и костыли рассказывать долго, а про ASM — быстро?

В рамках курса нам достаточно подмножества асма. Количество команд, сравнимое с количеством пальцев. Этих команд нам уже будет достаточно для понимания сути этого всего. Доступ к памяти, простая арифметика, перемещение данных в регистры (mov) и ветвление. Всё остальное — суть вариации над этим (и парочка спец-команд для сильного колдунства, которые будут объяснены тогда, когда реально потребуются). Если эти концепции усвоить, то остальные команды можно изучить самостоятельно (по мере потребности в них). Там документация такая, что по ней можно свой процессор собрать (точнее ей действительно так пользуются). В плане структурированности — настоящее гикпорно.

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