О двух интересных проектах

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

Rustboot

Первый проект – это rustboot, небольшое ядро написанное на Rust. На данный момент ядро не умеет делать ничего полезного, кроме как рисовать красный экран в QEMU, хотя один из клонов пошел немного дальше и, похоже что, поддерживает на ARM-архитектуру и даже пользовательский ввод текста

Написание ядра ОС на Rust стало возможным благодаря модулю zero.rs, который позволяет создавать Rust-приложения не использующие Rust-рантайм. Еще одним примером использования zero.rs является rust.ko – минимальный модуль ядра для Linux, так же написанный на Rust.

Решения интересные и неожиданные, хотя, лично у меня, вызывают один вопрос: есть ли какой-то практический смысл в использовании Rust для подобных задач? Выгода – гарантии по-памяти на этапе компиляции. Минусы: плюшки в виде задач и поддержки сети исчезают, ООП – никакое. Может, все-же, лучше C++1Y?

OSv

На мой взгляд, данный проект куда более интересен и полезен – ОС написанная специально для того, что бы работать в облачном окружении. ОС однозадачная by-design, т.е. совсем-совсем однозадачная – она может выполнять только одну задачу, но это позволило сильно упростить архитектуру ОС. Идея выглядит логично, так как OSv позволяет запустить, к примеру, одну инстанцию JVM и, по утверждению авторов, производительность того же Memcached запущенного на OSv превосходит его-же на Linux. Что вполне ожидаемо.

А на закуску – OSv написана не на каких-то там Си, а на C++ и не просто на C++, а C++11! Код новой ОС открытый и доступен на GitHub.

9 Comments О двух интересных проектах

  1. count zero

    > есть ли какой-то практический смысл в использовании Rust для подобных задач?

    Сейча – вряд ли, а вообще – да, безусловно.

    > Выгода – гарантии по-памяти на этапе компиляции. Минусы: плюшки в виде задач и поддержки сети исчезают,

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

    > ООП – никакое.

    По сравнению с чем оно “никакое”? На первый взгляд, там есть всё, что необходимо, и по сравнению с Си – это щастье с большой буквы Щ.

    > Может, все-же, лучше C++1Y?

    Особого технического смысла нет, да и Линус тупо не пустит в ядро Си++.

    > Идея выглядит логично

    IBM уже делала что-то такое (CMS в VM/370 и z/VM) – что-то не слышно о ее успехах на поприще хостинга.

    Reply
    1. Alexander Stavonin

      А что позже случиться такого, что сделает Rust хорошим языком для написания ОС? Я, вроде как, большой сторонник этого языка, но все же, на мой взгляд, в ОСописательстве он слегка полезнее чистого Си, т.е. особых бенефитов не несет. Тот же C++1Y – будет куда более полезной штукой при написании ОС нежели Rust.
      ООП никакое по сравнению с C++. Метапрограммирование в таком сравнении тоже сливает.

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

      Reply
      1. count zero

        > А что позже случиться такого, что сделает Rust хорошим языком для написания ОС?

        Его таки зарелизят и вместо костыльного zero.rs сделают что-то приличное (или доведут до ума zero.rs). Если кто-то придумает, как нормально интегрировать в ядро задачи (привязать их к обработчикам прерываний, к вызовам из юзерспейса, асинхронному выполнению) – будет вообще пушка.

        > на мой взгляд, в ОСописательстве он слегка полезнее чистого Си

        Модель управления памятью, дженерики, трейты – это для “слегка”?

        > Тот же C++1Y – будет куда более полезной штукой при написании ОС нежели Rust.

        Чем? Не скажу, что внимательно смотрел OSv, но там используется довольно ограниченное подмножество Си++.

        Reply
        1. Alexander Stavonin

          Лично я на замену костыльного zero.rs не рассчитываю, все же основная цель Rust не драйвера писать.

          > Модель управления памятью, дженерики, трейты – это для “слегка”?

          Конечно, слегка. По сравнению с C++1Y все достаточно примитивно, кроме модели памяти, которая “умные указатели”, безусловно, превосходит.

          > Не скажу, что внимательно смотрел OSv, но там используется довольно ограниченное подмножество Си++.

          Так и от Rust же только небольшое подмножество можно использовать. А как показывает практика, затянуть почти весь STL и половину BOOST на уровень ядра задача вполне выполнимая.

          Reply
          1. Count Zero

            > все же основная цель Rust не драйвера писать.

            Цель Rust – системное программирование. Тот, кто скажет, что написание драйверов – это не системное программирование, пусть первый бросит в меня камень.

            >> Модель управления памятью, дженерики, трейты – это для “слегка”?
            > Конечно, слегка

            А, ну тогда ой.

            > По сравнению с C++1Y все достаточно примитивно

            Хм. И чего не хватает? Только с примерами, для чего нужна остуствующая возможность.

            >> Не скажу, что внимательно смотрел OSv, но там используется довольно ограниченное подмножество Си++.
            > Так и от Rust же только небольшое подмножество можно использовать

            Мне всё еще интересно, чем это “небольшое” подмножество Rust хуже, чем небольшое (без кавычек) подмножество Си++, используемое в OSv.

          2. Alexander Stavonin

            Написание драйверов – самое что ни на есть системное программирование. Просто по моим ощущениям, Rust это в первую очередь user-mode язык и Servio отличная иллюстрация того, для чего его создают.

            Очень-очень не хватает нормального ООП: наследования (включая множественное, хотя без множественного прожить можно) и виртуальных функций. Так же слабое метопрограммирование (то что делается при помощи MPL не сработает на шаблонах Rust). Остальное все будет на уровне стандартной библиотеки, т.к. в ядре явно заработает не все что есть в Rust уровня пользователя. Примеров я тебе врятли тут приведу, или ты хочешь примеров того, когда наследование полезно? :)))

            > Мне всё еще интересно, чем это “небольшое” подмножество Rust хуже

            Если говорить о user-space, то ничем не хуже, т.к. минусы компенсируются плюсами. С kernel-space все сложнее, т.к. количество плюсов падает (как минимум исчезают задачи), а количество минусов возрастает (те же задачи + исчезает рантайм, подозреваю что с изрядной долей стандартной библиотеки).

  2. count zero

    > по моим ощущениям, Rust это в первую очередь user-mode язык и Servio отличная иллюстрация

    Странно. Ты же есть (или был?) в rust-dev@ и мог видеть, что за последние месяцы минимум 3 проекта хотят Rust на голом железе, и основные разрабы поощрительно относятся к этому.

    > Очень-очень не хватает нормального ООП: наследования (включая множественное, хотя без множественного прожить можно) и виртуальных функций.

    Что не так с трейтами? Насколько я понимаю, это и наследование, и виртуальные функции.

    > о что делается при помощи MPL не сработает на шаблонах Rust

    “Не нужно” (ц) LOR

    > или ты хочешь примеров того, когда наследование полезно?

    Я хочу примеров, когда “слабое ООП” Rust мешает. Кроме того, наследование _чего_? Наследования реализации в Rust нет, наследование интерфейсов – есть (трейты могут расширять другие трейты).

    >> Мне всё еще интересно, чем это “небольшое” подмножество Rust хуже
    > Если говорить о user-space, то ничем не хуже, т.к. минусы компенсируются плюсами. С kernel-space все сложнее, т.к. количество плюсов падает (как минимум исчезают задачи), а количество минусов возрастает

    Забавно. Как по мне, так дела обстоят ровно наоборот – в ядре можно использовать весь _язык_ Rust (задачи – это библиотека), но только часть языка Си++ (как минимум, нет исключений).

    Reply
    1. Alexander Stavonin

      Я рассылку получаю, но читаю выборочно, на доскональное изучение нет времени. Видимо я эти хотелки пропустил, так как мне они мало интересны.

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

      Если говорить о слабом ООП в Rust, то оно мешает всегда, т.к. ты не можешь наследовать функционал. Я допускаю, что ты привык писать в таком стиле, но при моей плюсовой “базе” это огромны минус, который можно простить за Задачи + сеть, но не более того.

      Ну так в ядре использовать _весь_ C++ за минусом исключений и _почти_всю_ стандартную библиотеку!

      Я не к тому, что C++ лучше/хуже Rust, а к тому, что Rust (да и C++, если честно) не kernel-level язык.

      Reply
      1. count zero

        > Я не к тому, что C++ лучше/хуже Rust, а к тому, что Rust (да и C++, если честно) не kernel-level язык.

        Rust как раз kernel-level, хотя его стандартная библиотека – нет. Си++… да без разницы уже. Если у него и был шанс, этот шанс давно упущен.

        Reply

Leave a Reply to Alexander Stavonin Cancel reply