Для ядра/ОС все еще C?

Я думаю, можно с уверенностью сказать, что низкоуровневые части операционных систем (например, ядро) будут продолжать писаться на C из-за его скорости. Как упоминалось в другом месте, вам нужно знать ассемблер для определенных частей ядра (что-то нужно для загрузки ядра в память). Но вы можете работать над ядром, практически не зная ассемблера. Хорошим примером может быть, если вы реализуете файловую систему.

Не беспокойтесь о том, на каком языке реализована операционная система. Важно то, как используются операционные системы и что можно сделать для их улучшения. Хорошим примером является время, когда впервые появилась Unix. В файловой системе индексные дескрипторы располагались в передней части диска, а данные — в оставшемся пространстве. Это работало не очень хорошо, так как вы искали разные части диска для всех файлов. Затем была создана Быстрая файловая система Berkeley, чтобы создать файловую систему с поддержкой дисков. Это означает наличие инодов рядом с соответствующими им данными. Я опускаю многие детали, но надеюсь, это показывает, что важнее думать о том, как можно улучшить операционную систему, а не о том, на каком языке она будет программироваться.

Некоторыми последними тенденциями в операционных системах являются виртуализация и распределенные вычисления (см. документ Google по MapReduce). Файловые системы, безопасность, планирование (особенно с многоядерными процессорами) и т. д. постоянно вызывают интерес, хотя эти проблемы не новы.

Вот некоторые ресурсы, если вы хотите узнать больше о разработке ядра:

• Linux Kernel Newbies — ресурс для тех, кто хочет начать модифицировать ядро ​​Linux.
• исходный код xv6 — порт Unix версии 6 для x86 , Используется Массачусетским технологическим институтом для проведения занятий по операционным системам. Простота и легкость расширения (дополнительная информация).
• Карта ядра Linux — цепочка вызовов системных вызовов в Linux. Полезно для визуализации того, что делает системный вызов.

Итог: начните знакомиться с ядром и читайте документы о том, о чем пишут исследователи (для этого полезен USENIX). ). Это знание гораздо более ценно, чем изучение нового языка, поскольку большинство концепций из одного языка можно легко перенести на другой, если случится изменение в написании операционных систем. Надеюсь это поможет!

Исследователи проявляют большой интерес к использованию языковых технологий, чтобы гарантировать, что ядро ​​не может вести себя неправильно. Несколько человек упомянули проект Singularity, который в настоящее время имеет (заслуженно ) Высокий профиль. Чем интересна сингулярность?

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

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

• Singularity использует технологию компиляции, а не технологию OS/MMU, чтобы изолировать один «процесс» от другого. Внезапно разветвляется новый «процесс» (действительно новый вид защитный домен) очень дешев, и эта дешевизна позволяет создавать новые конструкции.

Singularity — лишь последний из длинного списка проектов, в которых для решения проблем ОС использовались технологии языка и компилятора. Одним из моих любимых было ядро SPIN Вашингтонского университета, которое позволяло приложениям безопасно расширять ядро. и был написан на Модуле-3.

Эта область исследований все еще широко открыта, и еще не известно, какой набор функций языка или компилятора является "золотым пятном" для решения проблем с ОС. Итак, чтобы ответить на ваш вопрос:

• В сегодняшних производственных системах C по-прежнему является "этим".

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

Коди не хотел утруждать себя ответом, поэтому я передаю это от его имени. :-P Некоторые примеры ОС, написанных на управляемых языках, а не на C или ассемблере, см. здесь:

• Singularity
• SharpOS
• Космос
• MOSA
• Фантом

Разумеется, Коди тоже не хотел упоминать об этом:

• Ренраку

C - это почти все, с изрядным количеством ассемблера. Важные темы для работы с ядром ОС включают:

• Принципы кэширования и управления кэшем
• Виртуальная память, управление TLB
• Процессор и системная архитектура
• Иерархии хранения
• Методы параллельного программирования (взаимное исключение, блокировка и т. д.)
• Алгоритмы и структуры данных

На самом деле в ядре современной ОС достаточно места для кода C++. Я только что посмотрел, и в дереве ядра ядра Win7 довольно много кода C++. Обратите внимание, что многие подсистемы остаются в простом C. На это есть несколько причин.

1. C - исходный язык ОС на базе NT.
2. C очень, очень хорошо понимается ключевыми людьми
3. Хорошо написанный C может быть самым простым кодом для отладки, особенно в режиме ядра.

При этом многие команды и люди считают хорошо написанный C++ эффективным инструментом для работы с основной ОС.

В C++ нет ничего, что мешало бы использовать его для написания основного кода управления ресурсами, такого как планировщик, диспетчер памяти, подсистема ввода-вывода, графическая подсистема и т. д. и т. д.

Как указывали другие, для любой работы с ядром всегда потребуется немного языка ассемблера.

Microsoft находится в процессе перезаписи части Windows на .NET, однако я сомневаюсь, что большая часть ядра будет затронута.

Однако есть такие проекты, как Cosmos (http://www.gocosmos.org/index.en.aspx ), которые дают нам надежду.

Нет, это не "это". Ядра обычно пишутся на C с добавлением небольшого количества ассемблера. Но ОС написана на самых разных языках. Но даже там C++ можно использовать без особых проблем. Как и многие другие языки. Linux написан фанатиками C, которые боятся и ненавидят все остальное, что является их проблемой. Windows написана на большой смеси C и C++ и, возможно, с некоторыми битами старого кода Pascal. И в наши дни также появляются куски .NET. OS X использует Objective-C для большей части кода ОС.

Тот же совет применим и во всех других областях программирования:

• Знай свое дело
• Не ограничивайте себя Единственным Истинным Языком.

Ядро — единственная область, где применяются несколько «особые» правила. Но ядро ​​крошечное. Подавляющее большинство ОС может быть написано на любом языке.

Да, вам обязательно нужно знать C, но просто знать C далеко не достаточно.

Вы можете ознакомиться с проектом Singularity от Microsoft (также в Википедии):

Singularity — это экспериментальная операционная система, разрабатываемая Microsoft Research с 2003 года. Она задумана как высоконадежная ОС, в которой ядро, драйверы устройств и приложения написаны в управляемом коде.

Только очень небольшая часть этой ОС написана на C, а остальная часть написана на языках более высокого уровня (Sing#, расширение C#). Я полагаю, что в будущем вы можете ожидать увидеть гораздо больше подобных вещей.

Я думаю, что это довольно безопасная ставка на то, что серьезная (не экспериментальная) разработка ОС останется на C (и сборке) в обозримом будущем.

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

Так что, если бы люди искали технически более совершенный язык, чем C, вы должны были бы повсюду видеть операционные системы, написанные на Ada, верно? На самом деле я вижу одну серьезную ОС, реализованную на Аде. Он больше не поддерживается в пользу повторной реализации на C.

Барьеры для других языков в разработке ОС никогда не были техническими. Я не думаю, что нетехнические преимущества C исчезнут в ближайшее время, и никто никогда не собирается преодолевать их, просто разрабатывая лучший язык.

Определенно! Вы также должны изучить хотя бы один язык ассемблера/аппаратную архитектуру.

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

• язык Си и
• Сборка

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

Я полагаю, что как разработчик ядра ОС вас больше будут волновать способы эффективного доступа к базовому оборудованию (например, процессору и памяти), а не выбор языка. Бьюсь об заклад, в большинстве случаев у нас будет искушение использовать ассемблер.

Я много занимался программированием как в Windows NT, так и в ядре Linux. И я могу заверить вас, что пока эти 2 ОС существуют вокруг C, они будут использоваться в ядре. Я думаю, что причин множество, но самый простой ответ — время. Как упоминалось в предыдущих постах, время, необходимое для переписывания ядра на другом языке, того не стоит. И это будет не просто портирование кода. Ядру потребуются серьезные модификации дизайна. Лично я считаю C наиболее подходящим языком для ядра. Возможность управлять вашей открытой памятью и динамически выделять и освобождать вашу собственную память имеет решающее значение, когда вы работаете в ядре. Особенно, если вы работаете со страничной памятью. Размер стека, выделенный вам в режиме ядра, также обычно меньше, чем в пользовательском режиме, поэтому эффективность использования памяти снова имеет решающее значение. C также позволяет программистам создавать красивые структуры данных, которые не содержат всех раздутых накладных расходов, присущих управляемым языкам. На мой взгляд, структуру можно использовать так же эффективно, как и объект, но опять же без раздутых накладных расходов. Управляемые языки также должны быть «управляемыми». В ядре у вас нет ничего, что бы убирало ваши беспорядки. Не поймите меня неправильно, я люблю C# и считаю, что фреймворк .NET прекрасен, но если вы работаете с ядром, то C есть и останется таковым.

C++ поддерживается для разработки режима ядра в Windows, но вы не можете легко использовать исключения и RTTI. Я считаю, что сегодня нет смысла писать код на C, поскольку накладные расходы C++ незначительны (любая инфраструктура трассировки/отладки будет намного дороже, чем дополнительное разыменование для вызова виртуальной функции). Фактически, большинство Windows DDK реализуют объектно-ориентированные шаблоны с помощью C, что просто неудобно по сравнению с C++.

Если вы решите использовать C++ для разработки в режиме ядра, вам потребуется переопределить оператор new, чтобы выбрать, следует ли размещать класс в выгружаемой или не выгружаемой памяти. Здесь могут пригодиться некоторые хорошие макросы.

Вы обязательно должны свободно владеть C.

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

1. Существующие операционные системы огромны, часто содержат миллионы строк кода и написаны на C или его производных, таких как Objective-C или C++.
2. Новым операционным системам требуются сотни инженерных лет (и многие календарные годы), чтобы достичь и соответствовать функциональности и надежности существующих операционных систем.

В результате мне трудно понять, как и когда мир отойдет от ядер операционных систем на основе C. Да, это технически возможно. Но цена может оказаться слишком высокой. Во всяком случае, тенденция, похоже, направлена ​​на консолидацию небольшого числа семейств ОС — Windows, Linux и BSD — все они основаны на C.

Было бы интересно узнать, какие исследования были проведены или какие инструменты и методы могут быть доступны для развития существующей кодовой базы (например, Linux) до лучшего языка. Я думаю, что это был бы гораздо более жизнеспособный подход, чем заставить мир принять совершенно новую ОС.

Ну, в сообществе osdev C обычно называют языком высокого уровня. И более «низкоуровневым» языком будет ассемблер (вы вынуждены использовать ASM в начале вашего ядра, поэтому вы должны использовать ASM, но вам не обязательно использовать C).

Я указываю на язык программирования Oberon и Операционная система Oberon от автора языка Pascal, Никлауса Вирт. У проекта Никлауса Вирта также есть фан-сайт.

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

Слишком часто можно услышать высказывание: язык C является синонимом скорости, а Ada — нет. Это не правда. Ада добавляет несколько проверок, которые замедляют выполнение. Это правда, но для целей отладки или безопасности. Следовательно, они могут быть удалены конфигурацией во время компиляции. Таким образом, вы можете генерировать программы ADA без накладных расходов. С другой стороны, обратите внимание, что компилятор gnu транслирует языки Ada и C в один и тот же промежуточный код. В результате вы получаете в конце тот же исполняемый код. Я прочитал здесь, что Ada нельзя использовать для разработки драйверов. Это неверно. Ада имеет те же возможности, что и язык Си. Более того, это позволяет избежать многих ошибок. Вы видите, что существует операционная система реального времени MarteOS, полностью написанная на Аде.

Основная причина, по которой Ада не используется для программирования ядра ОС, заключается в том, что язык C используется для Unix. Это норма POSIX, когда API системных вызовов выражается прототипами C. Все фрагменты ОС уже написаны на C. И язык C представляет 17% программного обеспечения, разработанного в мире.

Наконец, Ада строгая, и многим это не нравится. Они предпочитают разрабатывать программное обеспечение с уязвимостями и тратить больше времени на отладку.