Pull to refresh

Comments 30

Ваш учебник по созданию ОСи — лучшее что я видел на русском языке, да и на инглише такого не найти. Самостоятельно въехать в тему osdev — очень не просто, затер ваш сайт до дыр — теперь у меня есть MyOS. Огромнейшее спасибо!
с нескучными обоями?
вот зря вас минусят( вы попали в самую точку — gui я начал писать именно с нескучных обоев.
habrastorage.org/webt/8-/xa/d_/8-xad_ut-tmrtuwuxwonmsgkvck.png
Если что, то подложка из macos — это для антуража и самообмана. Картиночки на скрине — тест отрисовки с прозрачностью, понятия не имею зачем я это делал)
Только вот там в коде много глюков, в основном из-за кривой реализации менеджера памяти. Поэтому в релизе это ядро одно сплошное неопределенное поведение
Это уже для самостоятельной работы) Тут главное — начать.
Просто замечательное хобби для души без дедлайнов и релизов на ближайшие лет 30.
Это точно. У меня аналогичный проект тянется с 2001 примерно года. Сам себе архитектор и творец, очень интересно.
Самое начало: phantomexos.blogspot.ru/2013/07/phantomex-multiboot.html?m=0
Рекомендация одна: пишите код. Пока достаточно его просто копипастить из блога(весь код рабочий) — работающее ядрышко в эмуляторе очень мотивирует.
UFO just landed and posted this here

Они не тяжёлые ровно до того момента, пока не возникает ситуация что нужно держать миллион сокетов и активно делать в них I/O.

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

не требует быть системным вызовом для работы (т.е. не требует ядерных привилегий)

Но тогда, насколько я понял, (стабильный?) интерфейс программа-ядро начнёт состоять не только из "вызовов функций", но и из read-only страниц памяти. vDSO, случайно, не лежит внутри конкретного скомпилированного ядра? У меня сложилось ощущение, что это такой способ не выдумывать стабильного интерфейса на содержимое этих страниц (о совместимости которого потом придётся задумываться), а выдать более понятные "геттеры" с интерфейсом обычной функции, которые хоть формально и не требуют ядерных привилегий, но жутко implementation-specific.

Получается, этот то же принцип, что используется в NT — слои kernel32, ntdll, которые отрабатывают то, что можно в user space и идут в ядро только когда иначе никак + доступные TEB, PEB.
А сам clock_gettime до и после теста у вас какой метод переключения использует?
В расширенном режиме и режиме совместимости vDSO использует.
Реализовано это разделение в x86-семействе аппаратно при помощи сегментной защиты памяти.

Говорят, вместо неё уже давно обычно используются страничная защита. Например, в Википедии про AMD64 написано:


Segmented addressing has long been considered an obsolete mode of operation, and all current PC operating systems in effect bypass it, setting all segments to a base address of zero and (in their 32 bit implementation) a size of 4 GB. AMD was the first x86-family vendor to implement no-execute in linear addressing mode. The feature is also available in legacy mode on AMD64 processors, and recent Intel x86 processors, when PAE is used.
Все верно, но в «старом» режиме, чистом IA32 вы можете использовать сегментацию без страничной адресации. Т.е. началось все с защиты сегментов, а уже потом…
Интересно, как все это теперь выглядит в свете того, что были обнаружены уязвимости в процессорах, которые Intel вынуждена срочно закрывать в с довольно приличным падением производительности.

В статье именно про это и написано, если вы её читали.

> Каждый раз, когда мы хотим что-то отобразить на мониторе, записать в устройство, считать с файла, нам приходится обращаться к ядру ОС.

начинаю ностальгировать аж :)
вот в наше время — записал в память — вывел на экран. с устройством — с портами пообщался или тоже с памятью. ну прерывания там ещё…
старое доброе время :)

понятно, конечно, что такое это неподходит для многозадачности, не защищает память процессов и т.д.
начинаю ностальгировать аж :)
вот в наше время — записал в память — вывел на экран. с устройством — с портами пообщался или тоже с памятью. ну прерывания там ещё…
старое доброе время :)

< :) >
А чего ностальгировать-то? Добро пожаловать в программирование простых микроконтроллеров.
Там до сих пор так. Никаких ОС. Прямой доступ к оборудованию. Только с дисплеем не так просто, приходится подавать на дисплей команды, формируя на его ногах нужные комбинации сигналов.
< /:) >

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

Давно пора провести глобальный рефакторинг компьютерной архитектуры — т.е. одновременно спроектировать и процессор, и операционную систему. Я тут уже несколько раз предлагал заново спроектировать всю архитектуру компьютера, построив его по клиент-серверной архитектуре, выделив отдельные процессоры для файловой системы, для сетевой подсистемы, etc; ну и пользовательские задачи запускать на отдельных процессорах, каждый со своей памятью (что автоматически создаёт заметные препятствия для атак типа Meltdown).

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

Начинайте проектировать, кто вам мешает? Через 50 лет расскажете, что получилось.

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

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

То, что вы предлагаете, уже и так сделано — у нас есть процессор внутри диска, сетевой карты, каждый со своей памятью. Драйвера современных ОС умеют пользоваться возможностями этих процессоров и, в некоторых случаях, перепрограммировать их.
Современные процессоры мало чего общего имеют во внутренней архитектуре по сравнению с теми, с чьим поведением они совместимы.
Ну да — процессоры совершенствуются. И ARM, и *86 — начинали без кэш-памяти и без суперскалярности. И что?

процессор реально исполняет совсем не то, что его попросила программа, а то, эффект от чего будет неотличим (кроме, может быть, производительности) от наивного исполнения программы при условии отсутствия в ней ошибок.
А что значит «то» или «не то»?
Вот команда "ADD AX,BX" должна сделать "AX+=BX"; и именно это она делает. А каким из способов внутри себя она это делает — совершенно неважно.

Драйвера современных ОС умеют пользоваться возможностями этих процессоров {внутри диска, сетевой карты, каждый со своей памятью} и, в некоторых случаях, перепрограммировать их.
А вот здесь мне хотелось бы пруф с указанием конкретной модели диска/сетевухи и описанием того, как это работает. Можно даже дать ссылку на опенсорсную операционку, где программирование процессора внутри диска/сетевухи можно посмотреть прямо в коде драйвера.

Но Вы не поняли, что именно я написал. Я предлагаю вынести на отдельный процессор драйверы диска/сетевухи, а также драйверы файловой системы и сетевых протоколов.
А что значит «то» или «не то»? Вот команда «ADD AX,BX» должна сделать «AX+=BX»; и именно это она делает. А каким из способов внутри себя она это делает — совершенно неважно.


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

Это важно разработчикам процессоров. Они могут изменить внутреннее устройство (добавить регистров, поменять схему сумматора), но при этом оставить возможность выполнять инструкцию ADD AX,BX.

А вот здесь мне хотелось бы пруф с указанием конкретной модели диска/сетевухи и описанием того, как это работает.


Из интересного — Mellanox BlueField-2 I/O Processing Unit. Из более доступного — любая сетевая карта от Intel, предназначенная для серверов. Вторые, конечно, не являются программируемыми в смысле общего назначения, но опенсорсные драйвера ixgbe и i40e умеют попросить карточку складывать пакеты по некоторым правилам в различные очереди. BPF вполне можно назвать программированием — у LLVM/Clang даже есть соответствующий таргет.

Я предлагаю вынести на отдельный процессор драйверы диска/сетевухи, а также драйверы файловой системы и сетевых протоколов.


Это как раз и происходит. Прошивки SSD умеют разбирать MFT в NTFS и FAT, сетевые карты умеют разбирать UDP, TCP, 802.1q и ещё кучу всего. Просто производители не торопятся «пускать» внутрь своих железок всех подряд. Такое внутреннее ПО позволяет полчить конкуретное преимущество, скрыть детали реализации и быть совместимым с протоколами предыдущего поколения, или же просто дать возможность исправить ошибки обновлением драйвера и/или прошивки.

Я предлагаю вынести на отдельный процессор драйверы диска/сетевухи, а также драйверы файловой системы и сетевых протоколов.


Вы предлагаете использовать для это специализированные процессоры или процессоры общего назначения? Одинаковые или разные (одного типа для сети, другого для файловых систем)? Сложные (как современные процессоры общего назначения от AMD или Intel) или простые?
Насчёт программируемого storage — тут есть разные направления.

Есть обратные активности, связанные с перенесением алгоритмов из storage в ОС, например host-managed SMR или файловые системы, требующие character-based MTD device для ручного управления страницами flash-памяти.

И есть активности, делающие storage более умным, всякие программируемые NVMe fabrics, например www.bittware.com/resources/building-nvme-over-fabrics
Sign up to leave a comment.

Articles