Очередная книга про разработку операционных систем

    image

    Приветствую!

    В последние несколько лет мне довелось в той или иной степени изучать исходники примерно трех десятков операционных систем. Все из них я уже наверно даже и не вспомню. В основном это были маленькие библиотеки для микроконтроллеров, но «большие» ОС тоже приходилось просматривать с разной степенью погружения.

    Всё это время я также наблюдал на разных ресурсах посты о «разработке ОС», которые в основном сводились к выводу «hello world» в QEMU, и сетовал на то, что не нужно путать ОС и «программу, которая может работать на голом железе». ОС это совсем не про работу на железе, это, в первую очередь, про синхронизацию и все такое прочее.

    Можно на это возразить, что кому интересна «академическая» разработка, тому надо книги читать, а не HOWTO-посты в интернете. С другой стороны, в книгах вроде трудов Э.Таненбаума тоже есть недостатки, которые и приводят к тому, что поток постов, упомянутых выше, не иссякает. Книга Таненбаума (про MINIX) все-таки довольно «высокого» уровня и многие вопросы, которые возникают на практике, там вообще не рассматриваются. И есть еще один момент. Развитие ОС общего назначения и ОСРВ исторически шло в противоположных направлениях: в UNIX-подобных ОС вначале появились однопоточные процессы, и только спустя время процессы стали многопоточными; в области ОСРВ было наоборот, вначале появились «однопроцессные» многопоточные системы, а уже потом процессов могло стать более одного. Есть мнение, что для изучения лучше как раз второй случай, потому что начинать можно с более простого и усложнять постепенно, а прийти в итоге к одному и тому же. Но я отвлекся.

    Всё это моё брюзжание встречалось окружающими и коллегами фразами вроде «критикуя — предлагай», «сделай лучше», «пианист играет, как умеет», " художника обидеть может каждый" и т.п. Поэтому однажды терпение лопнуло и я сказал ок, challenge accepted. И сел писать свой вариант того, «как надо».

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

    Когда объем дошел до 250 страниц, стало понятно, что надо вовремя остановиться. Эта работа, в общем-то, так и осталась незаконченной, но, тем не менее, я думаю, даже в таком виде книга хорошо иллюстрирует концепцию и может быть полезна интересующимся темой. По отзывам, читать ее довольно сложно, так что если будут какие-то предложения, как можно было бы это пофиксить, я бы был за них благодарен.

    На мой взгляд, ОС — это ответ на совокупность проблем, которые возникают при необходимости огранизации работы нескольких независимых задач. Поэтому начинать нужно с описания проблем и возможных подходов к их решению, а не просто сказать, что вот исторически так сложилось, давайте обсуждать, как именно сложилось. Так что книга не то чтобы противопоставляется классическим работам, а скорее дополняет их и предлагает немного другой взгляд на вещи со стороны встроенных систем и ОСРВ.

    Хотелось обсуждать те вопросы, которые стоят не перед теоретиком, изучающим курс операционных систем в университете, а перед программистом. Поэтому обсуждаются вопросы вроде «почему синхронное переключение контекста это в целом не очень хорошая идея?», «что качественно меняется в ядре при необходимости поддерживать изолированные процессы?» и т.д.

    Есть также точка зрения, что операционным системам еще предстоит пережить архитектурную и мировоззренческую трансформацию, похожую на ту, которую пережили компиляторы из-за разделения на фронтенд и бэкэнд в виде LLVM. Поначалу от этого разделения не было видно никакого эффекта, программист использовал компилятор одинаковым образом и до и после. Но именно это разделение сделало возможным появление Rust и прочих языков, чьи создатели смогли сразу сосредоточиться на семантике своего языка, а бэкэнд использовать готовый. Так же и ОС было бы желательно разделить на несколько частей таким образом, чтобы всё это писалось разными людьми как независимые проекты.

    В качестве иллюстрации описываемых принципов используется FX-RTOS, как один из возможных подходов в том числе и к этой проблеме. Разумеется, для того, чтобы можно было описывать одни части ядра не касаясь других частей, оно должно быть написано таким образом, чтобы позволять это. Хотя тут я ставлю телегу немного впереди лошади, потому что сначала все-таки появилась сама ОС, а потом уже стало понятно, что ее архитектура хорошо подходит для того, чтобы на ее примере изучать предмет, так как можно наращивать функциональность очень мелкими шагами и вводить все понятия постепенно.

    Упомянутые выше исходники могут использоваться для иллюстрации концепций вплоть до 6 главы включительно, дальше уже можно плавно переходить к MINIX.

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

    Скачать книгу можно бесплатно без регистрации и СМС вот здесь.

    Всем спасибо за внимание, критические отзывы приветствуются, но, если они по объему больше двух предложений, то лучше писать в личные сообщения, потому что комменты имеют тенденцию разрастаться и превращаться в дерево обсуждения смежных вопросов, с которым сложно и неудобно работать.

    P.S. Если тема окажется интересной, позже напишу про саму FX-RTOS.

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 35

      0
      критические отзывы приветствуются

      Зачем PDF, если книга не версталась под печать? Лучше выложить на GitHub Pages. Так будет гораздо удобнее и быстрее принимать исправления.


      Права на данный текств полном объёме принадлежат КомпанииЭРЕМЕКСи защищены законодательством Российской Федерации об авторском праве и международными договорами.

      На условиях какой лицензии я могу копипастить код из книги?


      Никакая часть настоящей книги ни в каких целях не может быть воспроизведена в какой быто ни было форме и какими бы то ни было средствами, будь то электронные или механические, включая фотокопирование и запись на магнитный носитель, если на это нет письменного разрешения КомпанииЭРЕМЕКС.

      Ни на каких, ясно, понятно. ┐( ̄ヘ ̄)┌

        +1
        Спасибо за отзыв.
        Изначально планировалась печать, потом планы поменялись и все отложилось на неопределенный срок. Переформатирование под github pages требует времени, которого пока нет, может быть, впоследствии появится.
        Лицензия впоследствии может быть пересмотрена, там приведена стандартная шапка для документации. Код можно копировать свободно. Но зачем… Код из книги почти во всех случаях неполный с вставкой многоточий вместо фрагментов, его цель — демонстрация принципа и не более того. Зато тот же полноценный и компилирующийся код, который лежит в репозитории, доступен на условиях BSD-лицензии, копипастить лучше оттуда.
          0
          От меня наоборот спасибо за PDF. Я может несколько консервативен, но читая книгу, даже электронную, хочу читать именно книгу, с постраничной разбивкой и нормальной версткой.
            0
            И вам спасибо!
            0

            Если я конвертну книгу в gh pages (пример) и сделаю PR письменное разрешение оформите?

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

                Так документация будет в вашем же репозитории вместе с md файлами из которых будет генерироваться содержимое. Или это не то самое "одно место"?

                  +2
                  Disclaimer: я сейчас свое личное мнение выражаю, а не мнение компании, которой принадлежит контент.
                  «Одно место» это не в смысле чужие сайты, а то, что PDF (и word из которого он генерится) все же нужен. Чтобы отдать редактору или корректору например, когда-нибудь в светлом будущем или вообще издательству. Если контент форкается в markdown и начинает существовать в двух форматах, то их нужно синхронизировать между собой на что нужно временные и прочие ресурсы.
                  Если markdown сделать основным и генерировать и word и PDF из него… Не знаю, по моему опыту markdown все же word и все его возможности заменить не может по части ссылок, оформления, генерации оглавления и так далее. Поэтому удалить word-оригинал — очень смелый шаг на который пока никто не готов. Не удалять его = поддержка двух вариантов текста со всеми вытекающими из этого последствиями.
          +1
          функционал ядра

          функциональность
            0
            Спасибо, там довольно много подобных ошибок, не было достаточно времени на вычитку. к сожалению.
            –2
            1. Заинтересовался книгой и FX-RTOS.
            2. Пошел на сайт
            3a) Скачал книгу.
            3б) Скачал пример мигания 3 светодиодами под FX_RTOS.
            4. Открыл пример.
            5. Увидел строчку
            MDR_PORTB->RXTX &= ~1;

            6. Перестал интересоваться FX-RTOS.
            7. Про книгу отпишусь позже.
              +2
              Остается только позавидовать уровню вашего перфекционизма, что единственная строка, способна полностью отбить охоту смотреть остальные тысячи строк :-)
              Вообще демо к самой fxrtos отношения не имеет, и, кстати, что с ней не так, с этой строкой?
                0
                1. Если данная программа расположена в разделе «демо» в официальном разделе, посвященном рассматриваемой операционной системе, на сайте фирмы, которая планирует продавать данную ОС, то она имеет отношение к самой ОС.
                2. Более того, логично предположить, что демонстрационные программы писали программисты, имеющие прямое отношение к разработке ОС как таковой.
                3. Самый простой способ навсегда потерять репутацию программиста встроенных систем в моих глазах (если Вас не устраивает моя скромная персона, то посмотрите на признанных авторитетов в этой области) — это написать прямую установку или сброс бита в регистре так, как сделано в этой строке (ключевое слово — макросы Аскольда).
                4. В данном контексте (3 асинхронные задачи под шедулером по таймеру) подобное обращение к регистру управления светодиодами выглядит особенно пикантно.
                  +1
                  1. Я не совсем это имел в виду, но пусть будет так.
                  2. Так и есть.
                  3. Здесь наши мнения расходятся. Философия этой ОС — KISS в его самом незамутненном виде, поэтому, в частности, для любого М3 может использоваться один и тот же бинарник ядра, даже не исходник.
                  Если для битов есть символьные константы, или можно использовать простые числа вроде 1 и 0, то я считаю что именно так и нужно делать. Рассуждения о том, что «программист может перепутать», могут завести не в ту сторону. А если он названия переменных перепутает? Это все от лукавого. Не нужно умножать сущности без необходимости, особенно в демо-примере из 100 строк в одном файле.
                  Макросы в С нужны в совсем терапевтических количествах, потому что они скрывают реализацию и мешают понять, что происходит на самом деле. Что вынуждает разбираться в их реализации, тратить время. Код на С должен выглядеть кодом на С и быть понятным с первого взгляда, нужно дважды и трижды подумать, прежде чем усложнять. Такая вот позиция.
                  4. Это as designed :) Нужно исходить из того, в чем была задача, собственно. А она была не в том, чтобы диоды мигали строго по очереди, а в том, чтобы визуально, при взгляде на плату было видно, что потоки переключаются и диоды как-то мигают. Можно с тем же смыслом было написать:
                  MDR_PORTB->RXTX = RANDOM();
                  Да, иногда возможна ситуация что переключившийся поток сотрет изменения, внесенные другим потоком. Но никаких негативных последствий это не повлечет. Если бы там были не диоды, а устройство, которое требует синхронизированной записи в несколько регистров, то все было бы сделано совсем иначе, с мьютексом.
                  P.S. Вообще, комменты плохо подходят для дискуссии, пользуясь случаем, приглашаю на наш телеграм-канал, где можно обсудить кодстайл и прочее в более интерактивном режиме :)
              0
              1. Начал читать книгу
              2. Проглядел по диагонали первые 22 страницы и не очень понял, зачем они.
              3. На странице 23 увидел псевдокод
              while (my_device->status != <код готовности устройства>);

              4. Задумался, как бы написать это лучше в виде псевдокода
              while (my_device->status != <код готовности устройства>); // откровенно неудачно - очень близко к железу но, скорее всего, на реальном железе не пойдет
              while !equal_status(my_device->status,<код готовности устройства>); // все еще слишком близко к железу, указан конкретный код
              while !ready(my_device->status); // все равно близко к железу, указан конкретный регистр
              while !ready(my_device); // а вот так хорошо

              5. Раз уж мы пошли по пути абстракций, надо идти до конца и изолироваться от железа насколько возможно, а вот реализовывать функцию ready следует в самый последний момент.

              PS. дошел до страницы 28, увидел фразу
              Блок кода, выполняемый с запрещенными прерываниями называется
              критической секцией.
              , задумался ЧЯДНТ, начинаю терять интерес к книге.
                +1
                дошел до страницы 28, увидел фразу

                Что с ней не так?
                  –1
                  Запрещение/разрешение прерывания — это вовсе не единственный вид мьютекса.
                    0
                    Там нигде и не говорится, что это единственный вид, на 28 странице-то. Это единственный вид гарантированно доступный на большинстве железа, которое в той главе обсуждается, скажем так. Мьютексы как мьютексы будут только в 6 главе.
                      0
                      Но определение Вы дали навсегда?
                      Например, во FreeRTOS для критических секций определенного типа применяется специальный флаг, который предотвращает переключение задач, но не запрещает прерывания вообще никак.
                        0
                        Насколько я помню — нет, но я могу ошибаться. Критическая секция в более общем смысле обсуждается, например, на странице 183. Но, может быть, не совсем внятно. Наверно, это следствие многозначности самого термина, это и участок кода и одновременно примитив синхронизации в некоторых ОС и спинлоки и т.д.
                        Спасибо, стоит пропдейтить этот момент и в главе 2 назвать критической секцией «взаимоисключающийся» фрагмент кода, а каким образом это исключение достигается, вынести за скобки.
                  0
                  2. Наверно не получилось у меня донести мысль. Если расписать словами, то она такая: 1 глава — «что нам хотелось бы получить»; 2 глава — «что у нас есть»; 3 глава — «какие у нас есть способы получить то, что нам хотелось бы из того что есть», здесь приходим к идее о том почему и зачем нужна ОСРВ. Начиная с 4 главы реализуем ее.
                  4. За код спасибо, да, приведенный вариант более абстрактный, учту в следующих редакциях.
                    0
                    Надеюсь, Вы не обидитесь на мои излишне пристрастные замечания. Вашу идею о подобной книге поддерживаю полностью, на русском языке подобных материалов совсем немного, поэтому хотелось бы, чтобы читатели ее учились на лучших примерах, выполненных в блестящем стиле.
                      0
                      Нет конечно, не обижаюсь :) Здоровая критика — всегда на пользу, я учту все замечания, когда руки дойдут.
                      Первоначально планировалось что это все-таки будет бумажная книга, которая пройдет редактуру, корректуру, верстку, рецензирование и прочее. Но все эти планы пока были поставлены на паузу и контент доводился силами самих программистов со всеми вытекающими… Поэтому я даже в тексте упомянул, что работа не закончена, но было решено ее выложить хоть так, чем оставить пылиться во внутреннем репозитории.
                  +1

                  Бегло пролистал — мне понравилось. Всё разжёвано, термины объясняются, сложность доступна для понимания, изложено хорошо.
                  Пишите ещё!

                    0
                    Спасибо!
                    0
                    Нужно было голосование прикрутить, нужен пост про саму ОС или нет… или можно ограничиться развернутым комментарием с ответами на вопросы вроде «почему вы не взяли готовый и распространенный FreeRTOS».
                      0
                      Кто-то на хабре писал комментарий, что в подобных опросах читатели в любом случае проголосуют «нужен».
                        0
                        По-всякому бывает… Сейчас буквально все кому не лень пишут такие «либы для контроллеров», и «еще одна» может создать впечатление еще одного недоделанного велосипеда.
                      0
                      С удовольствием прочту, спасибо.
                        0
                        У меня по ссылке выскакивает «Forbidden. Access denied.»
                          0
                          Поспрашивал сейчас у разных знакомых — у всех все качается. Даже и не знаю в чем тут может быть проблема. Если совсем никак не получится скачать до вечера — могу на почту отправить.
                            0
                            С российского IP forbidden, через VPN нормально.
                          0
                          Есть вот такая серия книжек:
                          www.fysnet.net/osdesign_book_series.htm

                          Книгу 3 я даже купил несколько лет назад, т.к. надо было поработать со странным устройством IDE на странном онтроллере, а самому ходить по граблям — не хотелось. В принципе, все по делу, нашел пару ммм… неточностей, есть в Errata.
                            –2
                            Если на микроконтроллере вам не хватает конечных автоматов, и приходится городить ртось, то вы явно что-то не так делаете: либо в довесок к МК надо нормальный процессор с MMU прикрутить, либо руки не из того места растут!
                              0
                              Очень категоричное заявление) Приведу пару доводов против него.
                              1. Невозможность воткнуть «нормальный процессор с MMU». Особенно стало остро с появление STM32H7. Встречал несколько проектов, где из-за требований к мелким габаритам ставили BGA минимального размера. И еще более мелкую DRAM к нему. RTOS там необходима была. По сути, там была часть для обычного МК +«тяжелые вычисления», которые гонялись на M7. Тут логичнее бы поставить просто одноплатник на QNX (есть требования к реальному времени) + МК, со своим ETH и все на прерываниях. Но увы. Габариты. В итоге все +- норм.
                              2. Конечные автоматы бывают порой настолько адовыми, что лучше не надо. И в таких случаях я склоняюсь к внедрению вообще виртуальной машины + скриптовые языки.
                              Сам в принципе против РТОС в МК, но порой это позволяет сделать проект читаемым и легко поддерживаемым. Порой даже приходится дописывать ту или иную РТОС (не ядро, а дополнительные меанизмы), чтобы снизить издержки, но все таки. Ясное дело, что ставить в STM32F030 РТОС не надо)))

                            Only users with full accounts can post comments. Log in, please.