Новая ветка ядра

Kernel architecture questions
  • Serge wrote:И это будет очень массивный и сложный костыль.
    Получается, что да.
    Serge wrote:По функциональности и объёму написаный с нуля код для long mode будет близок к микроядру.
    Очень похоже на то. Разница с микроядром в том, что при таком подходе в момент завершения функциональность сразу окажется на текущем уровне Колибри. Минус V86.
    Serge wrote:Не спорю. Тогда придётся для всех public-процедур писать обёртки для вызова их из сегмента с другой разрядностью, которые будут конвертировать параметры и завершаться не ret, а jmp far.
    Есть такое дело. Значит, нужно стремиться к минимизированию необходимости вызова процедур одной разрядности из другой разрядности.
    Serge wrote:Менее амбициозная попытка сделать Kolibri PE и то захлебнулась.
    Собственно, я исходил из того, что моё предложение заведомо менее амбициозно, чем переписывание всего с нуля.
    Ушёл к умным, знающим и культурным людям.
  • tsdima wrote:А ещё, обёртка должна будет грузить все сегментные регистры "своими" значениями и восстанавливать после вызова процедуры.
    А вообще, интересно, что будет, если 32-битный код будет обращаться к 64-битным сегментам. GP Fault?
    Ничего не будет. Сегментные регистры игнорируются в 64-режиме
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • diamond
    Собственно, я исходил из того, что моё предложение заведомо менее амбициозно, чем переписывание всего с нуля.
    Поэтому я и написал что реально сделать только микроядро без обвеса. В лучшем случае ещё будет драйвер клавиатуры и консоль на чём и завершается большинство разработок. Но гибридный вариант 32/64 представляется ещё менее реалистичным.
  • Мне 32bit хватит до конца дней, а вот если ориентироваться на хомячков, то да, нужно за 64bit думать.
    Не в курсе, но если qemu может эмулировать 64bit, то я смогу принимать участие в проекте как прикладник.

    ..bw
  • bw
    http://ru.wikipedia.org/wiki/QEMU
    Если не наврали, то поддерживает.

    To All
    В этой теме подняли очень важный вопрос, а именно: "голяк" в приложениях при старте нового 64-битного ядра. Когда я в свое время пытался продумать реализацию микроядра, соответствующая тема имеется, то данный вопрос был одним из первых. Однако он имеет достаточно эффективное решение: для 32-битных приложений можно поднять специальный сервер (или "демон" оперируя терминологией *nix), который будет транслировать запросы программ Колибри32 к новому ядру (подобно wine). Не забываем что Long mode имеет несколько хитрых вкусностей (В Win64 спокойно работают большинство 32-х битных программ, так же как и в Linux 64 можно запустить 32-х битные программы). Достаточно эффектный пример такого решения мы уже имеем. Так что я думаю на первых порах можно получить работающую систему текущего уровня и параллельно заниматься написанием новых родных и переписыванием старых приложений под новое ядро.
  • Не забываем что под микроядро сложнее программировать. Запросы от приложений будет просто некуда транслировать очень значительное время.
  • Serge
    Это лучше чем написание всего с нуля сразу.
  • Извините, что вмешываюсь не совсем в свое дело, просто забавно наблюдать, как о том, за что здесь некоторое время назад меня лишь только пинали, начинают задумываться местные ядерщики (и не только). Что наконец-то пришло понимание о реальных перспективах текущего варианта системы?
    
Я не злорадствую, а просто подчеркиваю, что отношение может меняться не только к 64-разрядной архитектуре и что людей нужно слушать, даже если вам не совсем нравится то, что они говорят.
    
П.С. По фактам отпишусь завтра с компа.
  • Phantom-84
    Перефразируя Хауса - Все ошибаются!
    А вообще все люди инертны - до некоторых вещей приходится дозревать.
    А еще мы очень любим пинать ближнего своего, но не потому что нам с этого польза, а просто так -за то что он другой... :oops:
  • Тоже вот решил нафлудить, хотя к КОСу никакого отношения не имею и вряд ли когда иметь буду :)

    Насколько могу судить, на сегодняшний день КОС представляет собой хаотическое нагромождение кода, сооружённого без какого-либо предварительного проектирования, откуда выползает куча проблем вроде невозможности по-человечески добавить поддержку нового устройства и т.п. Похоже, всем отметившимся в теме понятно, что такое положение ненормально, и что ОС вообще-то надо сначала проектировать, а потом писать (кодировать). Во всяком случае, это дошло даже до Максимыча (которому я это тысячу раз говорил в аське -- как и многое другое, что он цитирует, иногда весьма вольно, в том числе и в этой теме :) ). Однако "нормальное" проектирование приводит в итоге к необходимости писать всю систему заново, а также, скорей всего, к несовместимости нового варианта с существующим в настоящий момент даже на уровне прикладных программ, поскольку, насколько я понимаю, API тоже по-человечески не проектировался, а создавался по ходу дела (понадобилось что-то -- впихнули в ядро соответствующую функцию, не особенно задумываясь о дальнейших последствиях).

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

    Кроме того, эволюционный путь даже при хорошем первоначальном проекте не всегда позволяет по-человечески добавить существенно новый функционал (например, ядро Линух для более-менее вменяемой поддержки SMP пришлось чуть ли не полностью переписать, поскольку изначально такой поддержки не было запланировано вообще), ну а эволюционное превращение плохого проекта в хороший, если и возможно в принципе, то потребует жутких костылей для согласовывания старого "плохого" кода с новым "хорошим", причём весьма вероятно, что сложность разработки и корректного прикручивания этих самых костылей будет выше, чем трудоёмкость разработки всего и вся с чистого листа. При использовании для разработки ассемблера эти сложности ещё более возрастают. Технически возможно извратиться и заставить работать совместно 32- и 64-разрядные модули ядра системы, но стоит ли овчинка выделки? В конце концов, Майкрософт не просто так в 64-разрядных версиях своих систем не поддерживает 32-разрядные драйвера режима ядра, да и вообще не шибко заботится о сохранении полной совместимости даже на уровне прикладных программ, хотя именно для Винды этот вопрос имеет первостепенное значение из-за количества уже существующего ПО и малой переносимости основной его массы.

    Теперь тонна флуда о возможном назначении самописной системы :) Максимыч где-то ранее процитировал моё мнение, которое я ему высказывал в аське, но вкратце повторюсь. Пытаться даже чуть-чуть потеснить на рынке существующие системы -- абсолютно безнадёжное дело; что-то может получиться, и даже очень удачно получиться, но лишь случайно, причём без всякой связи с достоинствами системы (в конце концов, две наиболее массовые ОС на ПК -- Винда и Линух -- очень далеки от совершенства, сам ПК -- крайне неудачная аппаратная платформа, а лежащий в его основе процессор архитектуры ИА-32 -- вообще, похоже, худшее из всего, что существует в природе, однако в силу совершенно нетехнических причин именно эта мегакривая архитектура стала доминирующей). Единственная ниша, где система может найти профессиональное, а не любительское применение -- это встраиваемые системы, однако там есть два "но". Во-первых, этот рынок не пуст, и в крупных проектах используются уже существующие ОС, которые не потеснить (QNX, OS-9, LynxOS, WinCE, клоны Linux, ещё несколько осей), поэтому можно претендовать только на всякую мелочь. Во-вторых, в большинстве встраиваемых систем используются процессоры, не принадлежащие к архитектуре ИА-32, причём из 32-разрядных безусловным лидером является архитектура ARM, а 16- и 8-разрядные архитектуры можно не рассматривать: первые вымирают в пользу ARMов и отчасти 8-разрядных, а 8-разрядные, как правило, работают вообще без ОС или с различными узкоспециализированными "микросистемами" (64-разрядные встраиваемые системы, по большому счёту, не встречаются за ненадобностью, хотя иногда применяются современные процессоры ИА-32). Однако разработка ОС не для ПК для большинства интереса не представляет, не говоря о том, что для этого нужно приобретать дополнительное оборудование (отладочную плату с ARM'ом, например), и в результате этим направлением занимается очень небольшое количество программистов (мне вот придётся этим заниматься по долгу службы, поскольку использовать кривой Linux никакого желания нет, коммерческие ОС маловероятны по финансовым причинам -- нольчайство удавится, если предложить такой вариант, а писать программы для "голого" железа попросту тяжело, учитывая необходимость постепенно наращивать функционал, включая поддержку обмена данными по RS-232/485, CAN, USB и локалке; но я в данном случае выступаю не в роли системщика-любителя, а в роли профессионального наёмного программиста, и выбирать работу особо не приходится). В результате получается, что для основной массы потенциальных разработчиков ОС единственной приемлемой аппаратной платформой является ПК, а это означает, что о рыночных перспективах ОС лучше вообще не думать и определяться лишь с тем, чем она должна быть с технической, а не "экономической" точки зрения.

    Наиболее привлекательной для большинства выглядит десктопная ОС. Что это означает на практике? С учётом нынешнего положения дел на аппаратном фронте и путей его развития: 1) 64-разрядность (32-разрядные процессоры ИА-32 вымирают, даже Атомы в недобуках поддерживаю 64-разрядный режим; кроме того, Майкрософт объявила, что Вынь-7 -- последняя ось, поддерживающая 32-разрядные системы, а это в силу положения сей фирмы на рынке является приговором, и чисто 32-разрядные процессоры смогут сохраниться в обозримом будущем разве что во встраиваемых системах, а эта область, как я уже говорил, для основной массы неинтересна); 2) полноценная поддержка SMP (кристаллы с единственным логическим процессором ещё выпускаются, но их всё меньше и меньше, в то же время всё большее распространение получают изделия с 8 логическими процессорами -- например, интеловские Core i7, ну а скоро их будет ещё больше); 3) полноценная поддержка PnP, ACPI и прочих современных стандартов (десктопная ОС, не умеющая "спать" или потребляющая туеву хучу энергии в режиме бездействия, является в наши дни откровенным отстоем независимо от других характеристик; про пляски с бубнами для поддержки, например, динамического подключения устройств USB вообще промолчим). КОС совершенно не удовлетворяет ни одному из этих трёх пунктов; более того, реализовать их без переписывания с нуля почти невозможно (о мегакостыльности при попытках совместить старое с новым я много флудил выше).

    В общем, мораль сей басни такова: чтобы у КОС было будущее, её надо делать заново с нуля, причём с создания проекта, хотя на этот этап и уйдёт уйма времени. По моим грубым прикидкам, небольшой коллектив квалифицированных специалистов -- 3-5 человек -- при наличии достаточного свободного времени сможет справиться с проектированием "верхнего" и "среднего" уровней, после чего можно начинать проектирование "нижнего" уровня и одновременно кодирование, примерно за год-полтора (естественно, предполагается, что эти люди достаточно знакомы с архитектурой ИА-32 и с упомянутыми выше и некоторыми другими стандартами, т.е. им не потребуется серьёзно учиться на ходу, в противном случае сроки увеличиваются; кроме того, они должны заниматься проектированием, а не бесконечными спорами, что лучше -- монолит или микроядро).
  • Цитата из мануала Intel:
    3.1.1 Intel® 64 Architecture
    Intel 64 architecture adds IA-32e mode. IA-32e mode has two sub-modes.
    These are:
    • Compatibility mode (sub-mode of IA-32e mode) — Compatibility mode
    permits most legacy 16-bit and 32-bit applications to run without re-compilation
    under a 64-bit operating system. For brevity, the compatibility sub-mode is
    referred to as compatibility mode in IA-32 architecture. The execution
    environment of compatibility mode is the same as described in Section 3.2.
    Compatibility mode also supports all of the privilege levels that are supported in
    64-bit and protected modes. Legacy applications that run in Virtual 8086 mode or
    use hardware task management will not work in this mode.
    Compatibility mode is enabled by the operating system (OS) on a code segment
    basis. This means that a single 64-bit OS can support 64-bit applications running
    in 64-bit mode and support legacy 32-bit applications (not recompiled for
    64-bits) running in compatibility mode.
    Compatibility mode is similar to 32-bit protected mode. Applications access only
    the first 4 GByte of linear-address space. Compatibility mode uses 16-bit and 32-
    bit address and operand sizes. Like protected mode, this mode allows applica-
    tions to access physical memory greater than 4 GByte using PAE (Physical
    Address Extensions).
    • 64-bit mode (sub-mode of IA-32e mode) — This mode enables a 64-bit
    operating system to run applications written to access 64-bit linear address
    space. For brevity, the 64-bit sub-mode is referred to as 64-bit mode in IA-32
    architecture.
    64-bit mode extends the number of general purpose registers and SIMD
    extension registers from 8 to 16. General purpose registers are widened to 64
    bits. The mode also introduces a new opcode prefix (REX) to access the register
    extensions. See Section 3.2.1 for a detailed description.
    64-bit mode is enabled by the operating system on a code-segment basis. Its
    default address size is 64 bits and its default operand size is 32 bits. The default
    operand size can be overridden on an instruction-by-instruction basis using a REX
    opcode prefix in conjunction with an operand size override prefix.
    REX prefixes allow a 64-bit operand to be specified when operating in 64-bit
    mode. By using this mechanism, many existing instructions have been promoted
    to allow the use of 64-bit registers and 64-bit addresses.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Ну, раз флудить, так флудить...

    Чтобы сделать что-то лучшее, нужны желание и возможность. Они есть?

    Еще толком не определились, что действительно следует улучшать, но уже захотели притянуть поддержку старых приложений и т.п. Так не пойдет! Может лучше наоборот начать с того, чтобы к имеющейся системе добавить абсолютно новый набор системных вызовов, который бы пока опирался в том числе и на старый набор, причем "особые" группы системных вызовов (графику, взаимодействие с устройствами на основе физической адресации, взаимодействие с конкретными видами ФС и т.п.) сразу оформить в виде независимых наборов сервисных функций, которые бы не относились непосредственно к ядру. Короче нужно идти не по пути расширения интерфейса ядра, а по пути добавления к ядру новых интерфейсов посредством существующего интерфейса ядра. Я использую многоуровневую систему введения новых интерфейсов. Прежде всего это серверы - ПО, предоставлющее совершенно независимые от ядра наборы сервисных функций, доступные в том числе и приложениям. Обращение реализовано через трап-шлюзы IDT - не слишком удачный вариант с точки зрения современной тенденции иметь одну точку естественного входа в пространство ядра, с чем я в общем-то согласен, но это было сделано еще в то время, когда сиколы/сисэнтеры мягко говоря были не очень популярны в отличии от интов. Я грезил добавлением подсистемы Линукс через int 80h к моему int 60h. В принципе серверы можно реализовать и без использования трап-шлюзов. Просто главный принцип моих серверов здесь выражен абсолютно четко - добавление нового интерфейса через стандартный для него номер (именно номер, а не имя), просто 0-5Fh у меня зарезервированы для системных нужд (можно сказать, что и 60h тоже, хотя по сути это просто уже установленная точка входа в "сервер ядра"). Еще один уровень - это наш незабвенный IOCTL - набор функций (виртуальных) устройств, в котором зачастую для одной и той же функции разных устройств имеются различия не только в ее назначении, но и в наборе ее параметров. Сейчас IOCTL у меня реализован как набор из 8 последовательных системных функций DeviceIO0-7, которые транслируются ядром в нереентерабельные функции устройств 0-7 через структуры, описывающие эти устройства. Есть идея расширить набор этих функций до 16 (добавив либо еще одну группу DeviceIO8-15, либо новую группу DeviceIO0-15). Хотя в принципе можно иметь одну единственную функцию DeviceIO и передавать номер функции устройства как отдельный параметр, тогда количество функций у устройств может быть практически неограниченным. DeviceIO0-7 доступны в том числе и приложениям, если устройства не заблокированы управляющими структурами (это что-то типа монтирования, см. далее). Open/Close-механизм для устройств у меня не используется - это такая фишка - устройство либо само заботится о своем единоличном использовании, либо захватывается управляющей структурой, либо его функции остаются транзакционными и доступными сразу нескольким клиентам. Последний уровень - это уровень управляющих структур, через который в систему могут быть добавлены не только новые интерфейсы, но и структуры нового формата, которыми частично может управлять ядро. Управляющие структуры позволяют задействовать максимально абстрактный уровень управления, но в принципе они завязаны на виртуальных устройствах (они и называются именно так, потому что позволяют управлять устройствами). Благодаря управляющим структурам, можно вводить новые подсистемы ядра и даже подсистемы, локализованные вне ядра, с закрытыми внутренними интерфейсами, доступными только этим подсистемам. Фактически управляющие структуры позволяют регистрировать новые внутренние интерфейсы одним сторонним ПО для другого стороннего ПО. Чтобы было понятно, о чем идет речь, скажу несколько слов о подсистемах ядра, использующих управляющие структуры. Сейчас таких подсистем две: консольная и файловая (VFS, включая своп). Консольная подситема использует управляющие структуры, описывающие физические консоли (пока подсистемой поддерживается единственная физическая консоль с одним устройством отображения), предоставляя одну виртуальную консоль каждому процессу ее запросившему, а файловая подсистема использует управляющие структуры, описывающие файловые системы, предоставляя файловые функции для работы с единой файловой системой. Драйверы регистрируют управляющие структуры определенного типа, чтобы дать соответствующей подсистеме внутренний интерфейс управления устройствами подходящих типов более высокого уровня (более абстрактный и более универсальный), чем IOCTL-интерфейс самих устройств, с которым работают эти драйверы. А подсистемы могут предоставить единый внешний интерфейс к разным управляющим структурам определенного типа, каждая из которых может быть смонтирована на множестве подходящих по типу и по своей внутренней структуре устройств.

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

    О коммерческом использовании пока и задумываться не стоит. Если нет продукта, как вы его собираетесь продавать? Если хотите продавать идеи, нужно прикрыть все форточки (лучше уйти в подполье) и искать покупателей. Кстати идеи-то хоть есть, на которые может возникнуть коммерческий спрос? Если получится более-менее качественный продукт, то и сферу его коммерческого применения можно будет найти. Конечно, не завоевать весь мир, но занять определенную нишу вполне реально. Здесь уже можно сделать упор на оригинальных приложениях определенного назначения, а система будет прилагаться к ним в довесок бесплатно или почти бесплатно ;), потому что вы не создаете эти приложения под другие программные платформы. Если вдруг кто-то слижет ваш софт, причем так, что не подкопаетесь, вступаете в честную (с вашей стороны) конкурентную борьбу и пытаетесь усовершенствовать ваш софт лучше/быстрее, чем ваши конкуренты.

    С ориентацией на определенные аппаратные платформы, типы компьютеров пока все просто: аппаратная платформа на базе процессоров IA-32, Intel/AMD 64 (фасм, генерирующий код для других чипов я пока не встречал, хотя макросредства фасма много чего интересного позволяют сделать :) ); компьютеры - десктопы, в последствии может и малые серверы на базе все тех же процессоров IA-32, Intel/AMD 64. Говорить про встраиваемые системы, даже на базе процессоров IA-32, Intel/AMD 64, никакого повода пока не вижу, хотя лично у меня мамка с Линухом :)

    IA-32 или исключительно Intel/AMD 64, а может их вообще совместить в одной системе? Как-то вы быстро поспешили в этой ветке отказаться от IA-32, несмотря на то, что KOS продолжает оставаться чисто 32-разрядной системой. Конечно все мы менее критично начинаем смотреть на Intel/AMD 64, хотя, как кто-то здесь сказал, это еще тот костыль (я бы после этого вообще запретил AMD добавлять что-то свое, а лишь следовать тому, что предложит Intel :) ), но о быстром уходе IA-32 со сцены по прежнему говорить опрометчиво (столько утиля так быстро еще никто не перерабатывал :) ). Совмещать тоже далеко не самый лучший вариант, несмотря на то, что на уровне приложений это не так уж сложно сделать, как впрочем и прослойку для трансляции 32-разрядных системных вызовов в 64-разрядные при условии, что они между собой похожи. Однако я по прежнему придерживаюсь мнения иметь две линейки системы - чисто 32-разрядную и чисто 64-разрядную. Тем более что если опираться на хорошо спроектированную, а не на быстро скодированную 32-разрядную систему, то на основе 32-разрядного варианта ядра и другого базового ПО в приемлемые сроки можно получить их 64-разрядные аналоги. Конечно, кое-что придется существенно изменить, но в целом 64-разрядная система должна оставаться внешне схожей с ее 32-разрядным прототипом и в частности ядро должно иметь аналогичный набор системных вызовов, работать на основе тех же базовых алгоритмов.

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

    Ну и несколько слов по поводу микроядра и монолита. Здесь кто-то верно заметил, что нет никаких оснований переходить на микроядро. Микроядро сейчас скорее модный тренд, нежели действительно прогрессивная технология. Масштабируемость, защищенность, стабильность лучше пытаться достичь за счет лучшей структурированности, модульности, более простой и максимально прозрачной реализации, специальных методов защиты и т.п. Как только я пытаюсь представить оригинальное микроядро KOS, написанное с использованием тех же принципов и подходов, которые использовались при написании текущего варианта ядра, мне сразу становится страшно. Компоновка монолитного ядра во время компиляции также является неприемлемым вариантом. Предпочитаю включать в ядро только те драйверы, без которых его функционирование становится действительно проблематичным. Это прежде всего достаточно универсальные драйверы, обеспечивающие простейший ввод-вывод для пользователя, работающие с базовой аппаратурой (процессор и память), использующие полученную от BIOS в реальном режиме информацию (например, те же APM, ACPI), управляющие стандартными для AT-архитектуры онбоард-устройствами, а также современными и не очень шинами (например, главный мост PCI, хотя здесь возможны варианты).

    P.S. Думаю, на сегодня хватит :mrgreen:
  • Phantom-84 wrote:Может лучше наоборот начать с того, чтобы к имеющейся системе добавить абсолютно новый набор системных вызовов, который бы пока опирался в том числе и на старый набор
    Возможно, и лучше, но сначала этот самый абсолютно новый набор надо спроектировать -- иначе опять получится нагромождение всего и вся, добавляемого "по мере надобности"...
    Про неправильно выбранный в настоящее время баланс между разработкой ядра и разработкой приложений я уже говорил здесь ранее. Пусть ядерщики занимаются внутренним строением ядра, а прикладники пока думают, какой сервис ядра им необходим.
    Опять-таки, это вопрос проектирования. Прикладник сможет сказать, что конкретно ему нужно, но не более того. Однако все потребности нужно увязать в систему, иначе -- бесконечные переделки и полный хаос. Собственно, единственная реальная польза от использования в самописной оси чужого АПИ (ПОСИХ или ещё что -- неважно) заключается в том, что устоявшийся "промышленный" АПИ наверняка содержит всё необходимое для создания полноценных приложений. К сожалению, это не означает, что данный АПИ будет действительно совершенным -- он может быть громоздкий, неудобный и всё такое; единственное, что гарантируется -- это достаточность.
    IA-32 или исключительно Intel/AMD 64, а может их вообще совместить в одной системе? Как-то вы быстро поспешили в этой ветке отказаться от IA-32, несмотря на то, что KOS продолжает оставаться чисто 32-разрядной системой.
    Ну, я человек совершенно посторонний, чужого труда мне не жалко :) Потому с лёгкостью утверждаю, что заниматься разработкой под 32-разрядный режим смысла нет, он умирает, пускай и не слишком быстро. Да, поддерживаться он будет ещё очень долго (возможно, дольше, чем мы проживём), но... Если на то пошло, совместимость с 8086 или 80286 тоже до сих поддерживается, но ведь под них оси не создают -- ибо абсолютно бесперспективно. То же касается и чистого ИА-32.

    Поддерживать две линейки системы, разработанной на асме, очень тяжело -- слишком большие трудозатраты, фактически нужны две команды разработчиков. Вот если б ось была на ЯВУ, этот вопрос стоял бы куда менее остро (а при грамотном проектировании и реализации вообще бы практически не стоял).
    Что касается сопутствующих технологший типа ACPI, PnP, PCI и т.п., то я считаю, что конечно их поддержка важна и нужна, но не следует смещать акценты с базовых аппаратных технологий (процессор и память) и алгоритмов в их пользу.
    Перечисленные технологии в современных ПК -- не менее базовые, чем процессор и память. Как можно собрать список имеющихся устройств, а значит, автоматически выбрать необходимые драйвера, если не поддерживать эти стандарты? Как можно обеспечить энергосбережение, если их не поддерживать? Ну и т.д. В общем, в любой оси, претендующей на современность, они абсолютно необходимы, ну а поскольку это вещи низкоуровневые, их надо принимать во внимание с самого начала проектирования системы, а не пытаться потом впихнуть.
    Ну и несколько слов по поводу микроядра и монолита. Здесь кто-то верно заметил, что нет никаких оснований переходить на микроядро. Микроядро сейчас скорее модный тренд, нежели действительно прогрессивная технология. Масштабируемость, защищенность, стабильность лучше пытаться достичь за счет лучшей структурированности, модульности, более простой и максимально прозрачной реализации, специальных методов защиты и т.п.
    Вот это точно. Микроядро имеет определённые практические преимущества, но и не менее определённые недостатки. Но главное в любом случае заключается в тщательном проектировании: как попало сделанная микроядерная ось будет работать ничуть не лучше паршивого монолита.
    Компоновка монолитного ядра во время компиляции также является неприемлемым вариантом.
    Этот вариант приемлем, но в специальных случаях: либо во время разработки, либо для встраиваемых систем. В нормальном десктопном варианте, конечно, система должна уметь грузить все необходимые кишки самостоятельно (а значит, поддерживать вышеупомянутые стандарты).
  • Phantom-84 и SII
    Вам очевидно ресурсов http://board.sysbin.com и http://osdev.ru уже не хватает - все превращаем в личную переписку?
    Впрочем ничего удивительного тему создал Максим, а жестко флудить в ней начали люди которые ничего не делали, не делают и не будут делать для проекта, о чем прямо заявлялось.

    З.Ы. Слив засчитан!
  • Who is online

    Users browsing this forum: No registered users and 2 guests