![image](https://habrastorage.org/webt/9x/4r/xs/9x4rxshz0aztkdn0myymtl5gkyg.jpeg)
Приветствую!
В последние несколько лет мне довелось в той или иной степени изучать исходники примерно трех десятков операционных систем. Все из них я уже наверно даже и не вспомню. В основном это были маленькие библиотеки для микроконтроллеров, но «большие» ОС тоже приходилось просматривать с разной степенью погружения.
Всё это время я также наблюдал на разных ресурсах посты о «разработке ОС», которые в основном сводились к выводу «hello world» в QEMU, и сетовал на то, что не нужно путать ОС и «программу, которая может работать на голом железе». ОС это совсем не про работу на железе, это, в первую очередь, про синхронизацию и все такое прочее.
Можно на это возразить, что кому интересна «академическая» разработка, тому надо книги читать, а не HOWTO-посты в интернете. С другой стороны, в книгах вроде трудов Э.Таненбаума тоже есть недостатки, которые и приводят к тому, что поток постов, упомянутых выше, не иссякает. Книга Таненбаума (про MINIX) все-таки довольно «высокого» уровня и многие вопросы, которые возникают на практике, там вообще не рассматриваются. И есть еще один момент. Развитие ОС общего назначения и ОСРВ исторически шло в противоположных направлениях: в UNIX-подобных ОС вначале появились однопоточные процессы, и только спустя время процессы стали многопоточными; в области ОСРВ было наоборот, вначале появились «однопроцессные» многопоточные системы, а уже потом процессов могло стать более одного. Есть мнение, что для изучения лучше как раз второй случай, потому что начинать можно с более простого и усложнять постепенно, а прийти в итоге к одному и тому же. Но я отвлекся.
Всё это моё брюзжание встречалось окружающими и коллегами фразами вроде «критикуя — предлагай», «сделай лучше», «пианист играет, как умеет», " художника обидеть может каждый" и т.п. Поэтому однажды терпение лопнуло и я сказал ок, challenge accepted. И сел писать свой вариант того, «как надо».
Кстати, за финансовую и моральную поддержку всего этого мероприятия хотелось бы поблагодарить компанию Эремекс, а также коллег, совершивших трудовой подвиг в виде чтения и редактирования первоначального черновика.
Когда объем дошел до 250 страниц, стало понятно, что надо вовремя остановиться. Эта работа, в общем-то, так и осталась незаконченной, но, тем не менее, я думаю, даже в таком виде книга хорошо иллюстрирует концепцию и может быть полезна интересующимся темой. По отзывам, читать ее довольно сложно, так что если будут какие-то предложения, как можно было бы это пофиксить, я бы был за них благодарен.
На мой взгляд, ОС — это ответ на совокупность проблем, которые возникают при необходимости огранизации работы нескольких независимых задач. Поэтому начинать нужно с описания проблем и возможных подходов к их решению, а не просто сказать, что вот исторически так сложилось, давайте обсуждать, как именно сложилось. Так что книга не то чтобы противопоставляется классическим работам, а скорее дополняет их и предлагает немного другой взгляд на вещи со стороны встроенных систем и ОСРВ.
Хотелось обсуждать те вопросы, которые стоят не перед теоретиком, изучающим курс операционных систем в университете, а перед программистом. Поэтому обсуждаются вопросы вроде «почему синхронное переключение контекста это в целом не очень хорошая идея?», «что качественно меняется в ядре при необходимости поддерживать изолированные процессы?» и т.д.
Есть также точка зрения, что операционным системам еще предстоит пережить архитектурную и мировоззренческую трансформацию, похожую на ту, которую пережили компиляторы из-за разделения на фронтенд и бэкэнд в виде LLVM. Поначалу от этого разделения не было видно никакого эффекта, программист использовал компилятор одинаковым образом и до и после. Но именно это разделение сделало возможным появление Rust и прочих языков, чьи создатели смогли сразу сосредоточиться на семантике своего языка, а бэкэнд использовать готовый. Так же и ОС было бы желательно разделить на несколько частей таким образом, чтобы всё это писалось разными людьми как независимые проекты.
В качестве иллюстрации описываемых принципов используется FX-RTOS, как один из возможных подходов в том числе и к этой проблеме. Разумеется, для того, чтобы можно было описывать одни части ядра не касаясь других частей, оно должно быть написано таким образом, чтобы позволять это. Хотя тут я ставлю телегу немного впереди лошади, потому что сначала все-таки появилась сама ОС, а потом уже стало понятно, что ее архитектура хорошо подходит для того, чтобы на ее примере изучать предмет, так как можно наращивать функциональность очень мелкими шагами и вводить все понятия постепенно.
Упомянутые выше исходники могут использоваться для иллюстрации концепций вплоть до 6 главы включительно, дальше уже можно плавно переходить к MINIX.
Для того, чтобы все не выглядело как совсем уж прыжок с места в карьер, пришлось добавить первые две главы, которые посвящены общим концепциям и железу. Программисты могут их пропустить без последствий для понимания остального.
Скачать книгу можно бесплатно без регистрации и СМС вот здесь.
Всем спасибо за внимание, критические отзывы приветствуются, но, если они по объему больше двух предложений, то лучше писать в личные сообщения, потому что комменты имеют тенденцию разрастаться и превращаться в дерево обсуждения смежных вопросов, с которым сложно и неудобно работать.
P.S. Если тема окажется интересной, позже напишу про саму FX-RTOS.
lain8dono
Зачем PDF, если книга не версталась под печать? Лучше выложить на GitHub Pages. Так будет гораздо удобнее и быстрее принимать исправления.
На условиях какой лицензии я могу копипастить код из книги?
Ни на каких, ясно, понятно. ¬(???)-
anonymous Автор
Спасибо за отзыв.
Изначально планировалась печать, потом планы поменялись и все отложилось на неопределенный срок. Переформатирование под github pages требует времени, которого пока нет, может быть, впоследствии появится.
Лицензия впоследствии может быть пересмотрена, там приведена стандартная шапка для документации. Код можно копировать свободно. Но зачем… Код из книги почти во всех случаях неполный с вставкой многоточий вместо фрагментов, его цель — демонстрация принципа и не более того. Зато тот же полноценный и компилирующийся код, который лежит в репозитории, доступен на условиях BSD-лицензии, копипастить лучше оттуда.
dream_designer
От меня наоборот спасибо за PDF. Я может несколько консервативен, но читая книгу, даже электронную, хочу читать именно книгу, с постраничной разбивкой и нормальной версткой.
anonymous Автор
И вам спасибо!
domix32
Если я конвертну книгу в gh pages (пример) и сделаю PR письменное разрешение оформите?
anonymous Автор
Я уточню, сейчас сезон отпусков, но скорее всего нет. И дело тут в том, что хотелось бы, чтобы весь контент был в одном месте, чтобы его легко было обновлять.
domix32
Так документация будет в вашем же репозитории вместе с md файлами из которых будет генерироваться содержимое. Или это не то самое "одно место"?
anonymous Автор
Disclaimer: я сейчас свое личное мнение выражаю, а не мнение компании, которой принадлежит контент.
«Одно место» это не в смысле чужие сайты, а то, что PDF (и word из которого он генерится) все же нужен. Чтобы отдать редактору или корректору например, когда-нибудь в светлом будущем или вообще издательству. Если контент форкается в markdown и начинает существовать в двух форматах, то их нужно синхронизировать между собой на что нужно временные и прочие ресурсы.
Если markdown сделать основным и генерировать и word и PDF из него… Не знаю, по моему опыту markdown все же word и все его возможности заменить не может по части ссылок, оформления, генерации оглавления и так далее. Поэтому удалить word-оригинал — очень смелый шаг на который пока никто не готов. Не удалять его = поддержка двух вариантов текста со всеми вытекающими из этого последствиями.