Комментарии 207
Спасибо за статью, интересно почитать подробней. А при чем тут в хабах Brainfuck? Или все-таки есть кусочки на нем?)
А главное — никаких отладчиков, выводи в текстовый режим, либо в окошечки — повисло — ставь return'ы.Для чего так себя мучать?
Сейчас есть DCI, который на современных десктопных платах включается тривиально, и в продаже открытой до сих пор есть Intel Galileo, у которой JTAG доступен через OpenOCD.
Понятно когда приходится прошивку на ранних стадиях через порт 80 отлаживать, потому что вокруг вообще ничего не инициализированно, но писать полноценную ОС без отладчика — это мазохизм и потеря времени.
Автоматизируйте все, что видите — сборку, развертывание, EFI stub напишите, чтобы легаси загрузку не использовать (заодно не придется в защищенный режим переходить, вы и так уже там), тратьте время непосредственно на ОС, а развертывание и тестирование пусть скрипты делают — им не скучно.
Дополню:
DCI это когда все что требуется — это дебажный A-A USB3.0 кабель и Intel System Studio(Если быть точнее — то его часть Intel System Debugger). В результате есть мощный отладчик, с ассемблером(а можно и C-шные исходники подложить), доступом к памяти и пошаговой отладке.
Еще есть консольный openIPC python cli интерфейс, который позволяет все это делать скриптами(System Studio тоже через OpenIPC ходит).
Даже загрузить в память таргета исполняемый код, настроить регистры и запустить на исполнение получится. Можно даже борду не перезаливать. Все автоматизируется на раз.
Ну и конечно пишите сразу под EFI — меньше геммороя.
DCI это когда все что требуется — это дебажный A-A USB3.0 кабель и Intel System Studio(Если быть точнее — то его часть Intel System Debugger). В результате есть мощный отладчик, с ассемблером(а можно и C-шные исходники подложить), доступом к памяти и пошаговой отладке.
Еще есть консольный openIPC python cli интерфейс, который позволяет все это делать скриптами(System Studio тоже через OpenIPC ходит).
Даже загрузить в память таргета исполняемый код, настроить регистры и запустить на исполнение получится. Можно даже борду не перезаливать. Все автоматизируется на раз.
Ну и конечно пишите сразу под EFI — меньше геммороя.
Кстати, mrlolthe1st у UEFI есть такая фишка, что ОС может использовать драйвера из Uefi, если у нее нет своих. В Uefi как правило большая часть уже проинициализиована (графика, сеть, USB, жесткие диски, fat32, ntfs, ext2,3 и прочее. Даже все процессорные ядра активны), так что остается только дергать API.
Я эту фишку только в документации читал, вероятно CodeRush может рассказать о ней больше.
Я эту фишку только в документации читал, вероятно CodeRush может рассказать о ней больше.
Тэгов в этой статье больше чем смысла. Все время на отладку текстового редактора ушло?
Нет, Вы, наверное, не поняли, тут даже речи о текстовом редакторе не шло. А основную часть времени заняло чтение документации по железу, реализацию и отладку драйверов по этим докам. Да и вовсе — текстовый режим, который AX=3, из 0x10 прерывания. С выводом не всё так легко, как вы думаете. Прочитайте тут, как организуется вывод на экран: muruganad.com/8086/8086-Assembly-Writing-Directly-to-Video-Memory-B800.html
а причем здесь прерывание DOS (int 21h), когда я так понял через BIOS-ное прерывание (int 10h) нужно выводить
Это был сарказм, намекающий на почти полное отсутствие какой либо технической информации в статье и явное злоупотребление тэгами. Например TCP встречается только в тэге и в списке того, что сделано.
Я писал напрямую в видеопамять во времена доса из реального режима процессора. Вот и интересно было бы узнать, как оно в 21 веке делается во времена UEFI и нативных 64 битных режимах, что стало проще, что сложнее.
Вот вы кстати начали с режима совместимости efi, прыгая по режимам, зачем? Использовали ли вы какие то из привилегированных режимов работы проца?
Я писал напрямую в видеопамять во времена доса из реального режима процессора. Вот и интересно было бы узнать, как оно в 21 веке делается во времена UEFI и нативных 64 битных режимах, что стало проще, что сложнее.
Вот вы кстати начали с режима совместимости efi, прыгая по режимам, зачем? Использовали ли вы какие то из привилегированных режимов работы проца?
Респект, но где сама ОС?
Круто!
Если такую ОСь немного доработать, то Вам можно собственные «стораджи» производить и продавать, тем более что сейчас рынок полок с NVMe имхо не достаточно освоен «гигантами»
Если такую ОСь немного доработать, то Вам можно собственные «стораджи» производить и продавать, тем более что сейчас рынок полок с NVMe имхо не достаточно освоен «гигантами»
Юсб это круто, но что кроме ФАТ32 читает?
Что с памятью? спокойно адресует до 4ГБ?
Что с сетью? пингует 8.8.8.8?
Что с памятью? спокойно адресует до 4ГБ?
Что с сетью? пингует 8.8.8.8?
Александр, огромный вам респект! С интересом ждём новостей по данной теме!..
1) не хочу навязывать, сам частенько грешу написанием прототипов в текстовом редакторе (хоть и навороченном), но IDE будет удобнее для подобной разработки (какой-нибудь codeblocks например).
2) посмотрел скрины в ВК, там файл исходников ядра перевалил за 15K строк, — не оч удобно на мой взгляд. Раскидайте функционал по файликам (с соответствующими функционалу именами), продумайте архитектуру для своего проекта: типа в папке drivers — драйвера, в core — ядро ОС, utils — всякие вспомогательные ф-ии…
Вопрос: каким компилятором пользуетесь?
1) не хочу навязывать, сам частенько грешу написанием прототипов в текстовом редакторе (хоть и навороченном), но IDE будет удобнее для подобной разработки (какой-нибудь codeblocks например).
2) посмотрел скрины в ВК, там файл исходников ядра перевалил за 15K строк, — не оч удобно на мой взгляд. Раскидайте функционал по файликам (с соответствующими функционалу именами), продумайте архитектуру для своего проекта: типа в папке drivers — драйвера, в core — ядро ОС, utils — всякие вспомогательные ф-ии…
Вопрос: каким компилятором пользуетесь?
1)Я использую VS 2017 Community для разработки — осень удобно
2)Нет, это я при помощи gcc собираю всё в один файл(cpp.exe ...)
Компилятор, как уже понятно — GCC
2)Нет, это я при помощи gcc собираю всё в один файл(cpp.exe ...)
Компилятор, как уже понятно — GCC
А главное — никаких отладчиков, выводи в текстовый режим, либо в окошечки — повисло — ставь return'ы.
В чем проблема прицепиться gdb к qemu?
Ааа… зачем монтировать диски к буквам… Это же неудобно… Даешь нормальный рут.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Потому что слишком ограничено. И либо провоцирует сложности с контролем доступа, если вы, к примеру, хотите в многопользовательской ОС использовать ваш Яндекс.Диск как каталог, но не давать доступа к нему другим пользователям. Либо заставляет создавать отдельные механизмы: вы знаете, что в Windows можно примонтировать диск в пустую NTFS папку? Вопрос: если в Windows с дисками считают необходимым иметь такую функциональность, то зачем реализовывать заведомо слабофункциональную систему в новой ОС?
Кроме того, попробуйте придумать, как выглядел бы тот же chroot с Windows‐подобным монтированием? А это ведь неплохой инструмент отладки изменённого окружения при неизменённом ядре.
Ещё вы с linux‐подобным монтированием вы можете отправить Program files на отдельный диск, даже если система пока не поддерживает ничего, кроме FAT32, а в FAT32 нет символических ссылок (не говоря уже о жёстких ссылках, которые для каталогов не поддерживаются нигде).
Ещё, кстати, а зачем в новой ОС обратные косые черты в пути? В бо́льшей части языков программирования это символ экранирования и потому нифига не удобен в путях.
Как вообще может быть жёсткая ссылка на каталог? это ж по сути просто ещё одно имя для одних и тех же данных, а каталог — это ж не данные, а просто узел в дереве путей.
Строго говоря, возможны разные реализации, но таки обычно директорий представлен специальным типом файла и описан в полноправной inode. Так что жёсткая ссылка на него допустима так же, как и на любой другой файл.
Как сказали выше, представления разные. Но каталог — это часто по сути просто специальным образом отмеченный файл, в котором в некотором виде хранится таблица соответствия имени файла в каталоге и его inode. «Жёсткая ссылка» на файл означает, что один inode присутствует в двух таких специальных файлах. Т.к. каталог — тоже файл — то с помощью hex редактора по идее можно сделать жёсткую ссылку на каталог. Но тут возникают проблемы целостности: что означает hardlink/.. в таком случае? И это не говоря уже о возможности подсунуть какой‐нибудь ничего не подозревающей программе, рекурсивно обходящей каталоги, каталоги с бесконечной вложенностью — а даже сейчас не все такие программы умеют обрабатывать бесконечную вложенность символических ссылок (привет, Vim, как ни странно).
На самом деле все эти сложности, вами описанные, «яйца выеденного не стоят». И вообще в ранних версиях Unix жёсткие ссылки на каталог были допустимы. Проблема с ".." решалось тривиально: записи "." и ".." физически присутствали на диске…
Отказались от них по одной, но очень серьёзной причине: подсчёт ссылок. Именно так работает «сборщик мусора» на диске. Вот если жёстких ссылок на каталоги нет — он гарантированно работает. А если есть — то не работает. Всё.
Отказались от них по одной, но очень серьёзной причине: подсчёт ссылок. Именно так работает «сборщик мусора» на диске. Вот если жёстких ссылок на каталоги нет — он гарантированно работает. А если есть — то не работает. Всё.
Как раз физическое присутствие на диске записей . и .. мешает делать жесткие ссылки на каталог (да и вообще любые ссылки) — потому что foo/bar/link/.. внезапно оказывается не то же самое что foo/bar.
Как раз физическое присутствие на диске записейА этого, внезапно, никто не может гарантировать и сегодня. Потому неясно чем вам помешают записи.и..мешает делать жесткие ссылки на каталог — потому чтоfoo/bar/link/..внезапно оказывается не то же самое чтоfoo/bar.
. и .. на диске и хардлинки — зато ясно, что «виртуальной» .. быть никак не может, если хардлинки разрешены.да и вообще любые ссылкиТем не менее симлинки на каталоги существуют — несмотря на все изобретённые вами запреты.
Эм…
На самом деле "." и ".." это и есть жесткие ссылки.
Например, можете убедиться в этом командой stat:
На самом деле "." и ".." это и есть жесткие ссылки.
Например, можете убедиться в этом командой stat:
stat /etc
stat /etc/..Хорошо, поправлюсь: физическое присутствие на диске записей . и .. мешает делать произвольные жесткие ссылки на каталог (да и вообще любые ссылки) — потому что foo/bar/link/.. внезапно оказывается не то же самое что foo/bar, что нарушает принцип наименьшего удивления.
потому что foo/bar/link/… внезапно оказывается не то же самое что foo/bar
Почему это не тоже самое?
Физическое присутствие на диске жестких ссылок не мешает делать произвольные жесткие ссылки.
Опасность заключается только в том, что пользователь может легко сделать зацикленный граф, и доверять пользователю, что он никогда не зациклит дерево каталогов нельзя. Поэтому пользовательская утилита этого просто не позволяет, но сама файловая система никак не пострадает, если делать жесткие ссылки на каталоги. Пока вы не зациклите, и все утилиты, которые будут рекурсивно пытаться что-то сделать, будут сбоить.
Потому что указывает совсем в другое место.
Я говорю не об опасности для файловой системы, а о несогласованности данных. Если на директорию сделали жесткую ссылку, то у нее теперь два разных родителя. А запись .. — одна, и показывает только на одного из них.
Какая несогласованность? По обеим ссылкам вы откроете те же самые данные.
Какая ведь разница в какое другое место указывает — символическими ссылками всегда пользовались, и никакой несогласованности не было.
Если на директорию сделали жесткую ссылку, это не значит что у нее два разных родителя, это значит что у нее два линка.
И… показывает не на родителя, а на директорию. ".." это не какая-то особая запись, это просто жесткая ссылка.
И вообще, после открытия файла, не факт, что вы знаете по какому имени открыли файл.
Какая ведь разница в какое другое место указывает — символическими ссылками всегда пользовались, и никакой несогласованности не было.
Если на директорию сделали жесткую ссылку, это не значит что у нее два разных родителя, это значит что у нее два линка.
И… показывает не на родителя, а на директорию. ".." это не какая-то особая запись, это просто жесткая ссылка.
И вообще, после открытия файла, не факт, что вы знаете по какому имени открыли файл.
Скажите, а если .. — это не особая запись, а всего лишь жесткая ссылка, которая вот совсем ничего не означает — зачем она вообще нужна?
Для создания двунаправленного ДЕРЕВА каталогов, а не однонаправленного графа, чтобы вы могли зайти и выйти из каталога.
Также жесткая ссылка "." нужна для работы с относительными путями, иначе во многих случаях вы не сможете указать относительный.
Ну почитайте же документацию.
Изначально в Unix суперпользователь мог (и до сих пор вроде может) создавать хардлинки на директории обычной командой ln.
Если у вас Linux, то это не сработает (а если очень нужно, можете заюзать лайфхак с mount --bind)
Начиная с MacOS X, Хардлинки на директории использует служба Time Machine.
Я не подскажу сходу, в каких файловых системах эти ссылки хранятся непосредственно на диске, а какие генерируются и лежат в памяти после первичного чтения дерева каталогов в оперативку, это уже потроха драйверов файловых систем. Но 99% POSIX систем будут вам возвращать hard link counter для директорий с учетом "." и "..".
Также жесткая ссылка "." нужна для работы с относительными путями, иначе во многих случаях вы не сможете указать относительный.
Ну почитайте же документацию.
Изначально в Unix суперпользователь мог (и до сих пор вроде может) создавать хардлинки на директории обычной командой ln.
-d -F --directory
-d, -F, --directory
allow the superuser to attempt to hard link directories (note: will probably fail due to system restrictions, even for the superuser)
allow the superuser to attempt to hard link directories (note: will probably fail due to system restrictions, even for the superuser)
Если у вас Linux, то это не сработает (а если очень нужно, можете заюзать лайфхак с mount --bind)
Начиная с MacOS X, Хардлинки на директории использует служба Time Machine.
Я не подскажу сходу, в каких файловых системах эти ссылки хранятся непосредственно на диске, а какие генерируются и лежат в памяти после первичного чтения дерева каталогов в оперативку, это уже потроха драйверов файловых систем. Но 99% POSIX систем будут вам возвращать hard link counter для директорий с учетом "." и "..".
Да читал я вашу документацию! Давайте лучше вы почитаете что я вам пишу?
Как только вы разрешаете произвольные хардлинки на директории — ваш граф директорий перестает быть ДЕРЕВОМ!
чтобы вы могли зайти и выйти из каталога
Вот вы зашли в каталог /foo/bar/link, а там ссылка .. указывает на какой-нибудь /baz. Как теперь вам выйти в каталог /foo/bar?
А если я напишу «sudo rm -rf /», то как мне потом работать с системой?
Тоже и в вашем случае — я вам поясняю, что с технической точки зрения, хардлинки на каталоги есть, активно используются, а в некоторых OS их можно даже просто брать и создавать. Но это не означает, что нужно простреливать себе ногу, не думая что и зачем вы делаете.
Тоже и в вашем случае — я вам поясняю, что с технической точки зрения, хардлинки на каталоги есть, активно используются, а в некоторых OS их можно даже просто брать и создавать. Но это не означает, что нужно простреливать себе ногу, не думая что и зачем вы делаете.
Как теперь вам выйти в каталог /foo/bar?А зачем вам выходить в /foo/bar из /baz?Как вам верно заметили в Unix (не путать c Linux!) жёсткие ссылки изначально присутствовали и никакой катастрофы это не вызывало. А вот как раз «мягких» не было. Потом добавили «мягкие» ссылки и запретили делать жёсткие — из соображений безопасности.
Как только вы разрешаете произвольные хардлинки на директории — ваш граф директорий перестает быть ДЕРЕВОМ!И кому это мешает? Только системе, которой недостаточно иметь счётчик ссылок, а нужен полноценный GC. Который делать поленились. И всё, соственно.
Наличие жёстких ссылок на каталоги требует реализации специального сборщика мусора, зато появляются новые возможности типа анонимных временных каталогов.
Вот, например, любопытная статья GCFS: a Garbage-Collected Filesystem for Linux.
Вот, например, любопытная статья GCFS: a Garbage-Collected Filesystem for Linux.
Вообще-то жесткие ссылки на каталоги постоянно используются для организации дерева каталогов.
Когда вы пишете ls -a, как вы думаете, такое "." и ".." в каждом каталоге? Это жесткие ссылки.
Когда вы пишете ls -a, как вы думаете, такое "." и ".." в каждом каталоге? Это жесткие ссылки.
И либо провоцирует сложности с контролем доступа, если вы, к примеру, хотите в многопользовательской ОС использовать ваш Яндекс.Диск как каталог, но не давать доступа к нему другим пользователям.
Проблема с софтом ЯД который по умолчанию не ставится в "Мои Документы" или профиль пользователя, а лезет в корень диска. На убунте если он пойдет в /YandexDisk с правами 777 вы-ж не будете линукс ругать?
Я не знаю про софт ЯД на Windows, на linux я вполне себе использую davfs2 для доступа к ЯД. В сообщении это просто пример того, что вы не захотите монтировать на букву диска, а не тычок в сторону Windows — как я указал там же, я знаю, что в Windows реально можно монтировать не только на букву, просто это видится отдельным механизмом, тогда как linux вариант выглядит более целостно.
А где можно посмотреть исходники, которые «Совершенный код» (в хабах)?
Очень хотелось бы почитать чуть более подробно и в деталях. Надеюсь на выход следующих статей.
А главное — никаких отладчиков
Вот это как-то непонятно.
Отладочный интерфейс(ы) уже встроен(ы) в QEMU (на выбор), сервер GDB — легок, протокол прост, на х86 не rocket science подпилить себе готовый. Это ведь колоссальная экономия времени, вообще любой значимый проект должен (и обычно так и есть) начинаться с создания адекватных отладочных и тестировочных средств. Даже самых простейших. Это многократ окупается!
Вы представьте, что мне надо отладить примерно 10000 строк(и это не шутка! Примерно столько занимает драйвер PCI вместе с EHCI)ссемблерного кода, я не думаю, что GDB мне в этом поможет лучше, чем мой метод.
10000 строк
но
столько занимает драйвер PCI (вместе с EHCI) ассемблерного кода
это всего лишь 2-3 тысячи строк на С. Пффф…
Вот что я вам скажу.
Долбление даташитов тоже дело нужное в нужное время и в нужном месте, но конкретно то, что вы долбите — окончательно устареет раньше, чем вы реализуете полноценную поддержку, используя лишь ассемблер (при этом асм в критических местах — это годно). Всего лишь года через 3 вы опять окажетесь там, с чего начинали.
So you run and you run to catch up with the sun but it's sinking
Racing around to come up behind you again.
The sun is the same in a relative way but you're older,
Shorter of breath and one day closer to death.
… ©
При этом вы проваливаете овладение инструментарием и методологией разработки, а это и есть собственно квалификация. Архитектурные вопросы ОС я даже не упоминаю — у вас просто руки не дойдут заняться серьезно.
(если что — и ОС писал, успешно — железяки прожили больше 15 лет, и ядро [Linux] портировал на альтернативные SoC [ARM, SH3])
Вот это как-то непонятно.
Бывают ситуации, когда отладчики скорее мешают. Например у меня сейчас некий проект для микроконтроллера(pic18f4550), где программа представляет собой практически один большой обработчик прерываний. В частности управляющий мощностью источника питания, питающего некую нагрузку. Ну и как прикажете это отлаживать? Если я где-то стопорну программу, перестанет обрабатываться прерывание. Напряжение источника питания уйдёт. Нагрузка если и не сгорит, то будет работать в совершенно нештатном режиме, выдавая непонятно какую диагностику… Вот и остаются только отладочные сообщения. Мне кажется для низкоуровневого программиста, умение работать без отладчика, навык такой же важный, как знание отладчика.
Умение пользоваться инструментами, облегчающими жизнь и ускоряющими разработку — намного важнее умения обходиться без них, потому что время — ресурс невосполнимый. Опыт работы без отладчика придет сам, когда придется попасть в ситуацию вроде вашей, и можно даже специально тренировать этот навык иногда, когда время позволяет, но разработка ОС общего назначения на уже работающем оборудовании с доступными (и весьма развитыми) средствами отладки — это мазохизм в чистом виде.
В основном с вами согласен, но есть некоторые аспекты, которые надо дебажить долго, много и упорно. К середине написание ОС я сам стал как процессор отслеживать ошибки, и это нереально круто: всего лишь взглянул на код — и ты сразу видишь ошибку.
Самая большая проблема в том, что этот подход не масштабируется. Это у вас пока еще ОС маленькая, и ума хватает охватить ее целиком, думать как процессор, и вот это все. Реальные системы давно уже не укладываются целиком в голову одного человека, и потому нужно всеми силами разгружать эту самую голову, автоматизировать всю рутину, изучать инструменты, подходы, заниматься упрощением, декомпозицией, короче — снижением когнитивной нагрузки. Чем проще в вашем коде разобраться — тем этот код лучше, и даже если сейчас вы сами в нем сейчас разбираетесь досконально и «сразу видите ошибку», уже завтра это обязательно изменится.
Ошибки, которые сразу видно, можно даже за ошибки не считать, потому что они тривиально находятся и справляются, и вот после того, как их исправили, начинается самое интересное — ошибки в железе, ошибки, которые не повторяются, ошибки, связанные с взаимодействием нескольких частей системы, и т.п., и чем больше инструментов вы освоите (санитайзеры, статические анализаторы, визуализаторы карты памяти, обработчики точек останова, и все остальное, придуманное для отладки именно «тяжелых случаев») — тем лучше будет и для вас, и для пользователей вашей ОС, если таковые появятся.
Ошибки, которые сразу видно, можно даже за ошибки не считать, потому что они тривиально находятся и справляются, и вот после того, как их исправили, начинается самое интересное — ошибки в железе, ошибки, которые не повторяются, ошибки, связанные с взаимодействием нескольких частей системы, и т.п., и чем больше инструментов вы освоите (санитайзеры, статические анализаторы, визуализаторы карты памяти, обработчики точек останова, и все остальное, придуманное для отладки именно «тяжелых случаев») — тем лучше будет и для вас, и для пользователей вашей ОС, если таковые появятся.
Поскольку тут речь идёт о драйверах, то надо вспомнить ещё и «недокументированные» и «неверно документированные» карты регистров и прочее в даташытах. Очень приятно бывает на такое наткнуться.
Что-то типа «end-user software must write 0xBEEFDEAD in D14F9x_411_12b after enable», а на практике там надо 0xFACECAFE записать до enable(всё взято с потолка и от балды). Кушать такие подарки очень вкусно и вредно для клавиатуры и психики.
Что-то типа «end-user software must write 0xBEEFDEAD in D14F9x_411_12b after enable», а на практике там надо 0xFACECAFE записать до enable(всё взято с потолка и от балды). Кушать такие подарки очень вкусно и вредно для клавиатуры и психики.
Еррату не забудь еще, которую никто не читает.
«Мы обнаружили, что при определенных условиях у нас процессор намертво зависает. Чинить мы это, конечно, не будем, поэтому вы просто софт с вот такими инструкциями не запускайте».
Или еще лучше, «мы тут после нескольких лет производства обнаружили, что наше замечательное железо с DMA иногда пишет в физическую память по вот этим адресам, и портит там все. Не кладите туда ничего важного больше.»
Тут с отладчиком то не отладишь, а без отладчика можно вообще с ума сдуреть.
«Мы обнаружили, что при определенных условиях у нас процессор намертво зависает. Чинить мы это, конечно, не будем, поэтому вы просто софт с вот такими инструкциями не запускайте».
Или еще лучше, «мы тут после нескольких лет производства обнаружили, что наше замечательное железо с DMA иногда пишет в физическую память по вот этим адресам, и портит там все. Не кладите туда ничего важного больше.»
Тут с отладчиком то не отладишь, а без отладчика можно вообще с ума сдуреть.
Бинарную совместимость с чем-то планируете? (или может уже есть?)
Будет совместимость с posix?
Так же передо мной стояла задача создать собственную архитектуру, удобную мне
Извините, а при чем тут архитектура?
POSIX это API, то есть программный интервейс приложений. Или я чего то не понимаю?
POSIX это API, то есть программный интервейс приложений. Или я чего то не понимаю?
У меня есть сказать по этому поводу.
В целом posix — это конечно интерфейс. Но этот интерфейс закладывает в своём api определенные черты архитектуры лежащей под ним системы. В posix заложены концепции процессов, многозадачности, примитивов синхронизации, файловой организации данных и ввода вывода и прочее…
Следуя posix, сложно написать что-то кроме unix(в широком смысле)…
В целом posix — это конечно интерфейс. Но этот интерфейс закладывает в своём api определенные черты архитектуры лежащей под ним системы. В posix заложены концепции процессов, многозадачности, примитивов синхронизации, файловой организации данных и ввода вывода и прочее…
Следуя posix, сложно написать что-то кроме unix(в широком смысле)…
Следуя posix, сложно написать что-то кроме unix(в широком смысле)…Windows NT изначально писалась под POSIX (именно потому сделать поддержку Debian/Ubuntu оказалось так просто: всё важное/сложное было в ядре начиная с первой версии, нужно было только кой-какие адаптеры доделать), тем не менее Windows не то, чтоб уж очень сильно на Unix похожа…
То, что Windows NT писалась под POSIX еще не означает что Windows NT POSIX-совместима. А вот если бы была совместима — была бы и правда на Unix похожа.
То, что Windows NT писалась под POSIX еще не означает что Windows NT POSIX-совместима.Она реализовывала POSIX.1 (но не POSIX.2) — иначе её нельзя было бы продавать госструктурам.
А вот если бы была совместима — была бы и правда на Unix похожа.Осталось понять что именно вы этой фразой имеете в виду… она была сертифицирована как POSIX-совместимая начина с самой первой версии… но на Unix не была похожа уже тогда…
«мне кажется, что тут произошла типичная подмена понятий, Вы путаете теплое с мягким»:). Ну, то есть, на мой взгляд, Вы заблуждаетесь.
POSIX имеет 4 раздела, здесь и далее можно проверить пройдя по ссылке. Один из них «Системные интерфейсы (англ. System interfaces) — список системных вызовов языка Си.», под интерфейсом также понимают раздел «Основные определения (англ. Base definitions) — список основных определений и соглашений, используемых в спецификациях, и список заголовочных файлов языка Си, которые должны быть предоставлены соответствующей стандарту системой.».
Также есть много профилей, в одном прямо сказано
Ну и так далее.
И главное в приведенной же ссылке есть раздел "POSIX для Windows", ну не будете же Вы утверждать, что Windows это «UNIX в широком смысле».
Следует отметить, что в списке POSIX совместимых, есть например Minix, а он как известно микроядерный, вот последнее (микроядерность) является архитектруной особенностью.
Извините за занудство!
POSIX имеет 4 раздела, здесь и далее можно проверить пройдя по ссылке. Один из них «Системные интерфейсы (англ. System interfaces) — список системных вызовов языка Си.», под интерфейсом также понимают раздел «Основные определения (англ. Base definitions) — список основных определений и соглашений, используемых в спецификациях, и список заголовочных файлов языка Си, которые должны быть предоставлены соответствующей стандарту системой.».
Также есть много профилей, в одном прямо сказано
Стандарт POSIX 1003.1 подходит не для всех операционных систем. Встраиваемые операционные системы не всегда реализуют поддержку тех или иных функций. Стандарт POSIX 1003.13 описывает подмножество стандарта POSIX 1003.1 для встраиваемых систем, которое разделено на 4 профиля. Профили были разработаны, чтобы обеспечить переносимость программ на уровне исходных кодов для операционных систем с ограниченными возможностями.
Ну и так далее.
И главное в приведенной же ссылке есть раздел "POSIX для Windows", ну не будете же Вы утверждать, что Windows это «UNIX в широком смысле».
Следует отметить, что в списке POSIX совместимых, есть например Minix, а он как известно микроядерный, вот последнее (микроядерность) является архитектруной особенностью.
Извините за занудство!
Спасибо за занудство :).
В качестве показательного примера, разрушающего высказанную мной выше концепцию, можно еще QNX вспомнить… Хотя, если не ошибаюсь, он не полностью posix, но он, во-первых, похож и пытается, а во вторых мало того, что микроядерный, так еще и может использоваться для создания распределенных систем…
Но таки, это все таже процесно-файловая система (как, кстати и виндоус).
QNX, кстати, весьма показателен в том плане, что он для поддержания посиксовских write/read поверх микроядра городит специальный менеджер файловой системы. На мой взгляд, это то что называется противоречащие друг другу параграфы. То есть, мы микроядро и у нас модель сообщений и мы можем в namespace, но мы так же и posix и не умеем в posix без ioservice… (Я передергиваю, конечно. Просто, хочу продемонстрировать, что ради posix приходится идти на жертвы).
…
У меня, кстати, встречный вопрос. Как в embox, который вроде как может в posix, соотносится концепция schedee, который, насколько я понимаю, не всегда процесс с, собственно, posix?
В качестве показательного примера, разрушающего высказанную мной выше концепцию, можно еще QNX вспомнить… Хотя, если не ошибаюсь, он не полностью posix, но он, во-первых, похож и пытается, а во вторых мало того, что микроядерный, так еще и может использоваться для создания распределенных систем…
Но таки, это все таже процесно-файловая система (как, кстати и виндоус).
QNX, кстати, весьма показателен в том плане, что он для поддержания посиксовских write/read поверх микроядра городит специальный менеджер файловой системы. На мой взгляд, это то что называется противоречащие друг другу параграфы. То есть, мы микроядро и у нас модель сообщений и мы можем в namespace, но мы так же и posix и не умеем в posix без ioservice… (Я передергиваю, конечно. Просто, хочу продемонстрировать, что ради posix приходится идти на жертвы).
…
У меня, кстати, встречный вопрос. Как в embox, который вроде как может в posix, соотносится концепция schedee, который, насколько я понимаю, не всегда процесс с, собственно, posix?
По поводу QNX и микроядра, могу только повторить, что уже сказал, это не связанные вещи. Как реализован системный вызов никого не интерисует, важно чтобы он был. То есть берем операцию чтения, в Linux это сискол с таким то номером, выполняется по сути дела на том же потоке, только в ядреной его части. В микроядре, происходит сискол, который отправляет сообщение в другой пользовательский поток (процесс, задачу, ...) и уже этот поток обрабатывает сискол, а потом точно также посылает ответ.
Но, еще раз повторю, с точки зрения интерфейса это вызов open/read/write сигнатура у них стандартная.
По поводу Embox, все тоже самое. Как организован планировщик не важно. Если вопрос про легковесные потоки, то Вы совершенно правы, это не полноценный posix. Но там фишка была в том, что нам удалось объекты синхронизации (те же мьютексы) использовать в этих легких объектах. Ну и да интерфейс pthread -ов остается если нужен. Причем, поскольку мы слегка ученые, мы не могли не сделать все максимально абстрактным, и в одной очереди планирования, могут крутиться все объекты, поскольку они наследованны от schedee.
По поводу процессов отдельная песня, но в большинстве случаев, это опять же одни и те же объекты планирования что и потоки. Например в linux clone создаст некий объект планировния, а его характеристики (процесс или поток) укажутся в качестве параметров. Ну и да, fork очевидно тяжелее чем pthread_create
Но, еще раз повторю, с точки зрения интерфейса это вызов open/read/write сигнатура у них стандартная.
По поводу Embox, все тоже самое. Как организован планировщик не важно. Если вопрос про легковесные потоки, то Вы совершенно правы, это не полноценный posix. Но там фишка была в том, что нам удалось объекты синхронизации (те же мьютексы) использовать в этих легких объектах. Ну и да интерфейс pthread -ов остается если нужен. Причем, поскольку мы слегка ученые, мы не могли не сделать все максимально абстрактным, и в одной очереди планирования, могут крутиться все объекты, поскольку они наследованны от schedee.
По поводу процессов отдельная песня, но в большинстве случаев, это опять же одни и те же объекты планирования что и потоки. Например в linux clone создаст некий объект планировния, а его характеристики (процесс или поток) укажутся в качестве параметров. Ну и да, fork очевидно тяжелее чем pthread_create
А удалось использовать легковесные потоки с ссылающими друг на друга драйверами устройств? Ну, допустим, когда драйвер block_device флешпамяти использует драйвер spi и так далее?
конкретно про блочкие устройства не скажу, но некоторые вещи (драйвера) были переведены на легкие потоки,
Интересна именно ситуация со вложенными драйверами, когда каждый драйвер предоставляет блокирующие операции. Получается, что первый драйвер должен для выполнения блокирующей операции несколько раз вызвать блокирующую операцию следующего драйвера. Чего as is в условии «лёгких потоков» он сделать не может, ибо не помнит, на чем он на прошлой итерации остановился.
Есть решение через предоставление специального апи с запоминанием состояния для таких операций. Мне было интересно, поддерживается ли что-то подобное в embox.
Есть решение через предоставление специального апи с запоминанием состояния для таких операций. Мне было интересно, поддерживается ли что-то подобное в embox.
А вот давайте перейдем по вашей же ссылке.
Часть 1. POSIX.1. Системное API для языка Си
… Стандарт описывал следующие темы:
- файлы с информацией о пользователях и о группах
- форматы архивов tar и cpio
Где находится /etc/passwd на винде? Кто-нибудь вообще хоть раз видел cpio-архив на виндах?
POSIX.2. Командная оболочка и утилиты
- командный интерпретатор (на основе System V Bourne shell)
И давно cmd.exe является sh-совместимым?
давайте.
Кто Вам сказал, что файлы с информацией должны как то конкретно называться?
Я видел, это просто архивные файлы в них свой формат упаковки информации, но никто не препятствует сделать свою утилиту которая бы понимала данный формат.
опять же никто не говорит, что cmd.exe это bash, но никто не запрещает запустить программу интерпретатор который превратит командную строку в совместимую с shell -ом
Cygwin предоставляет все перечисленные Вами средства. Хотя я могу и ошибаться, давно не использовал. Есть еще MinGW, если мы говорим именно о совместимости на уровне программных интерфейсов.
Где находится /etc/passwd на винде?
Кто Вам сказал, что файлы с информацией должны как то конкретно называться?
Кто-нибудь вообще хоть раз видел cpio-архив на виндах?
Я видел, это просто архивные файлы в них свой формат упаковки информации, но никто не препятствует сделать свою утилиту которая бы понимала данный формат.
И давно cmd.exe является sh-совместимым?
опять же никто не говорит, что cmd.exe это bash, но никто не запрещает запустить программу интерпретатор который превратит командную строку в совместимую с shell -ом
Cygwin предоставляет все перечисленные Вами средства. Хотя я могу и ошибаться, давно не использовал. Есть еще MinGW, если мы говорим именно о совместимости на уровне программных интерфейсов.
Кто Вам сказал, что файлы с информацией должны как то конкретно называться?
Ну так и я спрашиваю как он называется и где лежит.
никто не запрещает запустить программу интерпретатор который превратит командную строку в совместимую с shell -ом
Cygwin предоставляет все перечисленные Вами средства.
POSIX именно что требует наличия такого интерпретатора с известным стандартной библиотеке Си именем. Но msvcrt.dll не знает ни про какой Cygwin.
PS Я утверждаю, что голая винда без Cygwin/MinGW/WSL — не POSIX-совместима. Каким образом установка Cygwin может это опровергнуть? :-)
а я утверждаю, что наличие раздела «POSIX для Windows» подразумевает, что Windows можно сделать в достаточной степени соотвествующим стардарту POSIX, а значит наличие интерфейса POSIX не накладывает никаких ограничений на архитектуру ОС.
Лично я не вижу противоречий между нашими утверждениями.
Лично я не вижу противоречий между нашими утверждениями.
а я утверждаю, что наличие раздела «POSIX для Windows» подразумевает, что Windows можно сделать в достаточной степени соотвествующим стардарту POSIX, а значит наличие интерфейса POSIX не накладывает никаких ограничений на архитектуру ОС.Накладывает. И довольно серьёзные. Просто поддержка POSIX.1 была в техзадании на Windows NT. А уже POSIX.2 и прочие — можно реальзовать отдельным аддоном если ядро у вас POSIX.1 поддерживает.
POSIX именно что требует наличия такого интерпретатора с известным стандартной библиотеке Си именем.POSIX.1 этого не требует, извините. А POSIX.2 не был реализован потому что требования контрактов с правительством требовали только POSIX.1
PS Я утверждаю, что голая винда без Cygwin/MinGW/WSL — не POSIX-совместима.Только уточните уж — о какой винде речь. Windows NT 3.1 и Windows 3.51 — совместимы. И с POSIX и с OS/2 (только 16 битный API) и даже с HPFS. А вот уже Windows NT 4.0 — нет, потому что требование поддержки POSIX перестало быть обязательным.
ОС под архитектуру x86
Почему не под архитектуру x64?
FAT32
Почему не ReFS?
SVGA
Почему не HDMI?
Зачем ты пишешь ОС которая на момент разработки уже не актуальна?
Лучше пиши ОС которая использует новейшие технологии и раскрывает весь потенциал ПК.
Подозреваю, в таком случае пост вышел бы через пару лет и назвался "написание собственной ОС за 3 года"
Во-первых:
Во-вторых: если начать сразу подниматься на Эльбрус без подготовки — вероятность дойти до вершины стремится к нулю — надеюсь, аналогия понятна?
В основном я преследую лишь спортивный интерес, получение опыта для себя в системном программировании и написания драйверов для устройств, которые используются повсеместно.
Во-вторых: если начать сразу подниматься на Эльбрус без подготовки — вероятность дойти до вершины стремится к нулю — надеюсь, аналогия понятна?
SVGA не разъем, а стандарт, HDMI же — разъем. Большинство юзеров пользуется шиндой, а там FAT32.
Архитектуры x64 не существует. x86 подразумевает под собой 386, 486, 586 — а это уже проц с поддержкой 64 битных инструкций.
Архитектуры x64 не существует. x86 подразумевает под собой 386, 486, 586 — а это уже проц с поддержкой 64 битных инструкций.
Большинство юзеров пользуется шиндой, а там FAT32
А разве там не NTFS?
Архитектуры x64 не существует. x86 подразумевает под собой 386, 486, 586 — а это уже проц с поддержкой 64 битных инструкций.
Присоединюсь к вопросу, почему не под систему команд AMD64?
большинство юзеров пользуется шиндой, а там FAT32.
Информация устарела лет на 10 минимум — по дефолту NTFS. Ну а FAT32 в основном на флешках.
NTFS является закрытой ФС, реверс-инженерить её нет желания.
Спеки опубликованы несколько лет назад
NTFS уже давно отреверс-инженерили, написали книги, написали открытый драйвер для линукса на Сях, а для КолибриОС — на ассемблере, я когда им занимался, даже красивую html документацию обновил. Чего ещё желаете?
FAT32 умеет 99% всяких утюгов и бетономешалок с USB/SD разъемом + она тупа и проста как пробка. На этом плюсы этой ФС заканчиваются. И выбор поддерживаемой ФС тут становится совершенно ясным.
Только за понимание тонкостей построения архитектуры (и там ниже про AMD64), я начинаю верить в перспективы Вашей ОС, желаю успехов, буду следить за проектом
А что такое «шинда»?
Я не помню современную популярную ОС, где в основном используется FAT32.
Я не помню современную популярную ОС, где в основном используется FAT32.
Никто и не говорит, что в основном используется, но поддерживать какую-то обратную совместимость тоже надо, а не писать сразу под все новые стандарты, позабыв о старых: а что, если понадобиться юзать что-то старое, или же на чем-то старом — в таком случае мы остаёмся в проигрыше.
1. Обратная совместимость нужна на всякий случай, а не «Большинство юзеров пользуется шиндой, а там FAT32.»
2. На FAT32 большинство пользователей windows ставили до 2000-го года. Почти 20 лет назад, на минуточку
3. Линейка современной Windows, которая началась с Windows NT СРАЗУ ставилась по умолчанию на NTFS, не путайте линейки WinNT и 9x — это разные системы.
Вы же почему-то не считаете, что большинство Линукс ставит на ext-1 1992 года выпуска?
2. На FAT32 большинство пользователей windows ставили до 2000-го года. Почти 20 лет назад, на минуточку
3. Линейка современной Windows, которая началась с Windows NT СРАЗУ ставилась по умолчанию на NTFS, не путайте линейки WinNT и 9x — это разные системы.
Вы же почему-то не считаете, что большинство Линукс ставит на ext-1 1992 года выпуска?
Я конечно ОС свою не писал, но помню по спекая Интел, что у x64 адресация памяти отличается от x86. Для x86 вроде бы сегментная адресация и пляски с соответствующем бубном, в x64 сегменты не используются и таблицы соответсвующие не нужны. Или я не прав?
Вообще не увидел разницы :(
Вся сегментная адресация в современных ОС сводится к созданию нескольких сегментов на всю память каждый, после чего они игнорируются.
ОС сводится к созданию нескольких сегментов на всю память каждый, после чего они игнорируются.
Нет. На x86 они используются для переключения задач разного уровня привилегий (между ring 0 и ring 3) даже в страничном режиме адресации. А вот на x64 вообще вроде как нет сегментной адресации, хотя могу ошибаться.
Не собираетесь поучаствовать в разработке опенсорс проектов — ReactOS, Kolibri и тд?
С удовольствием бы поучаствовал.
В Redox OS тоже вероятно пригодились бы ваши знания?
Написал в ЛС
ОС Haiku — сейчас вышла в бету. Посмотрите, красивая в части реализации. Нуждается в разработчиках.
Я обычно за велосипеды минусы ставлю, но тут всё как-то без претензий велосипед, прочитал — как будто в ностальгические девяностые-нулевые попал. В хорошем смысле. Однозначно хочется продолжения)
Когда в далёком 2002-2003 тоже баловался написанием ОС. Всё порываюсь в своей файло помойке найти исходники (если найду, то выложу на github)
Функционала совсем мало было реализовано: загрузка с дискеты 3.5" (Помню, как будто вчера было: AA55 =) ), и обработка прерываний от клавиатуры и мыши. USB, помоему, ещё небыло.
Функционала совсем мало было реализовано: загрузка с дискеты 3.5" (Помню, как будто вчера было: AA55 =) ), и обработка прерываний от клавиатуры и мыши. USB, помоему, ещё небыло.
Мне кажется, что свою ОС — это даже круче чем свою программа.
Я уже несколько раз говорил, что каждый хороший программист должен иметь свою программу.
Хотя, согласно последним исследованиям британских ученых для рабочих проектов нужны и программисты — простые гребцы.
Часто такие ребята для проекта (устоявшегося) представляют больший интерес чем гении.
Я уже несколько раз говорил, что каждый хороший программист должен иметь свою программу.
Хотя, согласно последним исследованиям британских ученых для рабочих проектов нужны и программисты — простые гребцы.
Часто такие ребята для проекта (устоявшегося) представляют больший интерес чем гении.
У меня вопрос о вашем бэкграунде (в части знаний).
Какими источниками помимо OSDev вы пользовались/пользуетесь?
В частности интересны источники информации по визуальной подсистеме. Какая архитектура в большей степени повлияла на данную разработку?
И, наконец, вопросы для статистики:
— Сколько весит ядро?
— Сколько времени эта весчь загружается?
Какими источниками помимо OSDev вы пользовались/пользуетесь?
В частности интересны источники информации по визуальной подсистеме. Какая архитектура в большей степени повлияла на данную разработку?
И, наконец, вопросы для статистики:
— Сколько весит ядро?
— Сколько времени эта весчь загружается?
Ни чо не понял. Где качать образ и какое железо поддерживается? Будет ли работать с винтами не в IDE режиме, а RAID без рэйда?)
Очень советую сделать отладчик через последовательный порт. Возможность посмотреть на память в рантайме — бесценно.
linuxdeveloper.blogspot.com/2012/05/debugging-linux-kernel-over-serial-port.html
linuxdeveloper.blogspot.com/2012/05/debugging-linux-kernel-over-serial-port.html
Драйвера на ассемблере или на C?
И на том, и на том
А есть какое то предпочтение или зависит от типа драйвера? (Просто новичок в этом и поэтому пытаюсь разбираться каждый день)
Какие-то части работы с девайсами гораздо проще сделать на ассемблерной вставке. К примеру девайс запускает сепулькирование по выводу в порт 0A67h значение 0A53h, об окончании он сигнализирует прерыванием F4h, а результат вычитвается из DS:ESI. На C писать такое может быть неудобным, а на ассемблере это всего несколько строчек.
Респект и уважение! Высшее мастерство — отделить нужное от ненужного, которого 99% у любой операционки из-за проблем совместимости или навороченности ненужными или редкоиспользуемыми фичами.
написание такой ОС, которая могла бы позволить максимальную производительность для каких-то конкретных задач
Так а под какие задачи писалось? И какого прироста производительности удалось добиться по сравнению с существующими решениями?
увлекательная задача, похожим страдал в 97-99-х годах, сначала Turbo Vision паскалевский на асм переписал, после с защищенным режимом разобрался и так же начал свою ОС пилить на чистом асме. Но, захотелось есть, на рынке платили только прикладникам которые задачи бизнеса решают и скатился по наклонной к жаве. :)
НЛО прилетело и опубликовало эту надпись здесь
Нет, это реальная ОС, расскажу в ближайшее время про все, что реализовано и как я это реализовал
НЛО прилетело и опубликовало эту надпись здесь
если парень виртуальную машину Java туда прикрутит и на ней можно будет запустить хотя бы какой Tomcat, а так же покажет увеличение производительности хотя бы на 10-15%, можно будет уверенно сказать что ОС имеет право на жизнь и на нее можно будет выделить десяток млн рублей для реализации нескольких экспериментальных фич которые будут востребованы на рынке частных бэкенд серверов.
Я бы порыл в две стороны Эльбрус и национальные производители бытовой электроники.
Я бы порыл в две стороны Эльбрус и национальные производители бытовой электроники.
BareMetal OS разве отменили?
Респект. Я бы поработал как дизайнер над визуальной частью
1) Интересно было бы сделать систему модульной. Т.е. чтобы любой желающий мог написать драйвер любой файловой системы и влить в операционку. Если в операционке поддерживается только FAT32 и не заложена возможность расширения — это мёртворождённый уродец.
2) Очень рекомендую использовать модель/API работы с драйверами — как у уже существующей системы, желательно Linux или FreeBSD. Чтобы можно было тащить драйверы оттуда.
3) Желательно отделить юзерский интерфейс (GUI, Shell) от остального — чтобы его можно было заменять. В т.ч. имеет смысл подумать об отказе от окон — как на смартфонах/планшетах.
4) Очень советую делать операционку кросс-платформенной. Вообще, изначально имело смысл закладываться не на 86, а на нормальный процессор типа ARM. Заодно не будет проблем с изучение дико сложной архитектуры 86, набравшей в себя массу исторического дерьма и вынужденной тянуть с собой всё это из-за боязни потерять совместимость со старыми программами.
5) Вы ничего не написали про API для юзерских программ. В идеале — надо бы смотреть в сторону POSIX.
6) Как тут уже верно заметили — не надо мапировать файловые системы на буквы, ведь их всего 26. Есть два хороших варианта:
- Как в Unix — монтирование в единое дерево файлов.
- Явно указывать источник файлов. Например: nfs: сервер:/путь/файл, smb: сервер:/путь/файл, hdd0:slice1:/путь/файл. Этот вариант интересен тем, что через механизм типа символьных линков можно будет подвесить все файловые системы на общее дерево. Также для источников файлов можно назначить однобуквенные псевдонимы/алиасы.
Про первое — это реализовано как драва в шинде. Второе — абсолютно согласен, но для этого нужны программисты и тп. Думаю, будет интересно обсудить все в телеге.
НЛО прилетело и опубликовало эту надпись здесь
Ну, вместо окон можно использовать фреймы.
А зачем Вам во время работы с калькулятором надо иметь на экране ещё что-то другое?
А зачем Вам во время работы с калькулятором надо иметь на экране ещё что-то другое?
НЛО прилетело и опубликовало эту надпись здесь
очень зависит от размеров экрана и плотности пикселов. На экране телефона кроме калькулятора на экране даже 720 пикселей — не влезет ничего, удобного для работы пальцами. Да и стандартное масштабирование HTML-страницы 1х будет смотреться крайне мелким. А даже на старых мониторах 1280х1024 или 1024х1280 можно много чего разместить — 2-4 окна, типа калькулятора (он у меня ранее был вынесен аппаратно в клавиатуру), браузер, записная книжка (от блокнота до ворда) и т.д. Сайты с узкой и единственной колонкой так и намекают на подобный стиль работы, когда при полноэкранном просмотре слева 30% и справа 30% свободного места, а можно выставить браузер на эти 40% экрана слева, а справа разместить еще несколько окон.
Еще популярны многомониторные конфигурации. В этом случае вы будете советовать размещать калькулятор в полноэкранном режиме на всех мониторах? У меня такое было, когда в гос.учреждении к ПК подключен аппаратный повторитель, дающий выход на монитор и проектор (к видеокарте подключен только 1 VGA, для винды также только 1 внешний монитор). Принес свой ноут и в режиме расширенного стола получил — на ноуте могу заниматься чем угодно (скидывать с флешки файлы и редактировать презентации, просмотр почты и прочее), а на мониторе+проекторе идет презентация. Раньше на одном мониторе+проекторе приходилось бы либо дождаться окончания презентации, либо ее прервать.
И даже в таких ситуациях вы будете предлагать свое?
Или перестали сталкиваться с чем-либо еще, кроме телефонов?
Еще популярны многомониторные конфигурации. В этом случае вы будете советовать размещать калькулятор в полноэкранном режиме на всех мониторах? У меня такое было, когда в гос.учреждении к ПК подключен аппаратный повторитель, дающий выход на монитор и проектор (к видеокарте подключен только 1 VGA, для винды также только 1 внешний монитор). Принес свой ноут и в режиме расширенного стола получил — на ноуте могу заниматься чем угодно (скидывать с флешки файлы и редактировать презентации, просмотр почты и прочее), а на мониторе+проекторе идет презентация. Раньше на одном мониторе+проекторе приходилось бы либо дождаться окончания презентации, либо ее прервать.
И даже в таких ситуациях вы будете предлагать свое?
А зачем Вам во время работы с калькулятором надо иметь на экране ещё что-то другое?
Или перестали сталкиваться с чем-либо еще, кроме телефонов?
Здорово! А насколько возможно Real-Time как функцию или опцию встроить?
Только вчера я сказал себе! «Наступило время, когда уже никто в одиночку не напишет систему или уже не возьмется за это»… И вот, пожалуйста. В карму автору и успехов!
Думаю, что данная ОС в настоящий момент наиболее интересна именно как сорс для знакомства с темой… Т.е. документацию почитали — хорошо, но не сильно понятно и остаётся это обычное «да блин, это профессора пишут, мне не пригодится, можно и забыть», а если потом провести практическое занятие и, например, перевернуть порядок бит в каждом секторе блочного устройства, да так, чтобы оно ещё потом и работало — вот это круто… У меня так знакомый с Ansible разбирался — залез в актуальную версию, сломал мозг, потом выкачал альфу и дошёл до v1.0 потихоньку, понял какие принципы в системе, теперь может эффективно в код лазить.
А потом его купит оборонка и засекретит разработки :)
Расскажите, как Вы реализовали TCP/IP стек. Вообще, мне очень слабо верится, что это все написано самостоятельно, а не скопипащено откуда-то. Но… может и есть еще гениальные люди.
К сожалению, работоспособных любительских ОС под desktop сейчас уже довольно много, а вот мобильных почти нет. Не планируете ли осваивать это перспективное направление?
Крутая статейка, я очень хочу помочь кодом! Как можно с вами связаться? Мне 1110 лет…
По вашему описанию, за полгода сделано очень многое. Если всё это написано с нуля самостоятельно, то поздравляю вас!
Интересует вопрос лицензии распространения? Будут ли исходные коды Open Source? И если да, то когда (или где уже сейчас) их можно увидеть?
Интересует вопрос лицензии распространения? Будут ли исходные коды Open Source? И если да, то когда (или где уже сейчас) их можно увидеть?
А где код?
На той же OSDev вроде как всегда рекомендовали при разработке ОС для x86 не начинать с бутлоадера, а реализовывать ядро изначально с поддержкой Multiboot specification. Загрузчик на современных x86-платформах — довольно такой «острый угол» (инициализация памяти хотя бы), интересно почему вы этот угол не «срезали»? Или идея была именно в «Bare-metal OS»?
В чем сложность инициализации памяти на современных х86? По сравнению с несовременными.
Смотря откуда начинать, если у вас уже все заведено и есть BIOS и его сервисы (т.е. либо старый интерфейс interrupt call, либо новый UEFI) — никакой разницы нет, память уже работает, карту бери у прошивки и действуй.
Если же ничего нет, даже стека, а вы сами из флеша исполняетесь — заводить современный контролер памяти DDR3/DDR4 (т.е. опросить сам контролер, добраться до SPD через SMBus, считать оттуда конфигурацию, отправить контролеру нужные команды в нужном порядке, выполнить тренировку, отключить неработающие модули, и все остальное) намного сложнее, чем раньше.
Если же ничего нет, даже стека, а вы сами из флеша исполняетесь — заводить современный контролер памяти DDR3/DDR4 (т.е. опросить сам контролер, добраться до SPD через SMBus, считать оттуда конфигурацию, отправить контролеру нужные команды в нужном порядке, выполнить тренировку, отключить неработающие модули, и все остальное) намного сложнее, чем раньше.
Закину в закладки, интересно почитать продолжения.
Когда-то писал свою ОС, со своими API для прикладного слоя и для драйверов, своей файловой системой, все полностью с нуля — от загрузчика до интерпретатора коммандной строки.
Вот только ряд комментариев на хабре отбил желание делиться результатами напрочь.
Когда-то писал свою ОС, со своими API для прикладного слоя и для драйверов, своей файловой системой, все полностью с нуля — от загрузчика до интерпретатора коммандной строки.
Вот только ряд комментариев на хабре отбил желание делиться результатами напрочь.
Сколько времени заняла разработка? Где бы глянуть исходники? Особенно интересует USB стэк. Загрузчик, FAT32, SVGA — это еще ладно, но вот все остальное — это ж куча пота. Снимаю шляпу.
Советую посмотреть ColibriOS kolibrios.org/ru. Она на чистом ассемблере, там парни тоже над ней трудятся и им тоже нужна помощь, может скооперируетесь.
Тоже хотелось бы себе создать ОС только для того чтоб можно было запускать через командную строку игры и не раскидываться всей оставшийся производительностью составляющей на всякие менюшки, уйма настроек которые никогда не трогал и трогать не собирался, непонятные запущеные +100500 службы и svhost которым конца и края нет.
А на чем и в какой среде всё было сделано?
Было бы лучше написать драйвер например под встроенную видюху intel hd graphics, ведь ваш SVGA в режиме 118h рисует графику через CPU, а это очень не правильный подход. Лучше ознакомьтесь со спецификациями gpu от intel 01.org/linuxgraphics/documentation/hardware-specification-prms
Да! Думаю, я этим займусь.
Я тоже считаю это отличной и перспективной идеей. Удачи в этом нелегком деле. Если что-то будет не получатся, а оно будет не получаться, советую спокойно к этому относится, работа не бывает легкой.
Не тратьте время на легаси технологии. Индустрия выкатила VulkanAPI на смену OpenGL, вот им и занимайтесь.
В одиночку лучше сразу застрелиться, чем лезть в эти 5000-10000 страниц описания. 2D ускорение лучше оставить на потом, когда уже всё остальное будет летать, и автор упрётся в производительность видеоподсистемы.
А сколько кнопок нужно нажать для переключения языка?
Не хочу обидеть автора, но пока без сорцов и перспективы их публикации, выглядит неправдоподобно. Хотелось бы больше деталей, а не обещания рассказать потом.
Еще один Minix. Хотелось бы, чтобы появилось и его описания аналогичное «Operating Systems: Design and Implementation» от Эндрю Таненбаума.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Написание собственной работоспособной ОС за полгода