ROS Kernel Roadmap Vgal — различия между версиями
(→3 - PNP manager) |
(→4 - PO manager;) |
||
Строка 90: | Строка 90: | ||
===4 - PO manager;=== | ===4 - PO manager;=== | ||
− | + | Его можно назвать либо белым листом, либо черной дырой, текущая функциональность крайне минимальна, так как она не нужна виртуальным машинам, UNIMPLEMENTED - это намного больше, чем IMPLEMENTED ... требуется анализ и добавление необходимой функциональности, а также настройка процедуры выключения ОС. | |
− | + | ||
− | + | ||
===5 - Drivers;=== | ===5 - Drivers;=== |
Версия 21:09, 26 мая 2021
https://jira.reactos.org/browse/CORE-16841
Содержание
[убрать]Roadmap ядра by Vgal
Аббреаиатуры:
- MM - диспетчер памяти
- CC - диспетчер системного кэша
- PNP - диспетчер plug and play
- PO - менеджер питания
- HAL - Hardware Abstraction Layer
- ACPI - Advanced Configuration and Power Interface
- PIC - Programmable Interrupt Controller
- APIC - Advanced Programmable Interrupt Controller
- UP - Uniprocessor
- MP - Multiprocessor
Очередность разработки:
Почему такая очередь? Логичнее начать с HAL. Для полной реализации драйвера NTFS (основной файловой системы для NT-совместимых систем) требуется функциональность CC, которая, в свою очередь, использует функциональность MM. Следовательно, это будет зеленый свет для развития NTFS.
1 - диспетчеры MM и CC
Рекомендуется совместная разработка, так как CC сильно зависит от MM. Кстати: https://reactos.org/blogs/memory-manager-development/, поскольку необходимо внести значительные изменения, а структуры разделов несовместимы, разработка должна выполняться в параллельных каталогах "ntoskrnl\mm_new\" и "ntoskrnl\cache_new\" (дополнительный ключ для Cmake -"MM_CC_NEW"). Это не повредит текущее ядро и будет безопаснее.
1.1.1 - основная задача на этом этапе - избавиться от _MEMORY_AREA, используя структуры _SECTION и _SEGMENT вместо PROS_SECTION_OBJECT и _MM_SECTION_SEGMENT. Соответственно, необходимо будет изменить код для поддержки работы секций и добавить недостающую функциональность.
1.1.2 - добавление инициализации системного кеша и недостающих функций для него.
1.1.3 - исправление MmAccessFault () и всех связанных функций
1.1.4 - тестирование, отладка, форматирование кода
1.2.1 - диспетчер CC, видимо, должен быть реально обновлен, поэтому он использует другие структуры (обе - «cc» и «cache»). Пока у меня нет окончательного решения. Анализ этой части еще не завершен.
1.2.2 - тестирование, отладка, форматирование кода
1.3.1 - на этом этапе должна быть реализована подкачка. Этот шаг можно будет реализовать позже.
1.3.2 - тестирование, отладка, форматирование кода
2 - HAL
Разработка должна вестись в отдельных каталогах "hal \ halxxx \". Это позволит сосредоточить усилия только на функциональности и не отвлекаться на совмещение разных версий (ускорение разработки). Это также более безопасно и не нарушит работу других HAL. RU http://vgal.ru.com/pic-ili-apic/
2.1.1 - ACPI APIC UP HAL (halaacpi.dll) изменить и добавить недостающую функциональность для процессора и контроллера APIC.
2.1.2 - тестирование, отладка, форматирование кода
2.1.3 - после завершения разработки использовать в "LiveCD" "halaacpi" вместо "hal"
его можно разработать после беты (или?):
2.3.1 - ACPI APIC MP HAL (halmacpi.dll) (нужна поддержка MP)
2.2.1 - ACPI PIC HAL (halacpi.dll)
2.4.1 - HAL PIC без ACPI (hal.dll)
2.5.1 - APIC UP HAL без ACPI (halapic.dll)
2.6.1 - APIC MP HAL без ACPI (halmps.dll)
2.7 - после завершения разработки объединить все HAL в один (при необходимости).
3 - PNP manager
Поскольку необходимо внести существенные изменения, разработка должна выполняться в параллельном каталоге «ntoskrnl \ pnp_new \» (дополнительный ключ для Cmake - «PNP_NEW»). Это не повредит текущее ядро и будет безопаснее.
3.1 - добавить arbiter-библиотеку;
3.2 - настроить и дополнить RTL библиотеку "rangelist.c";
3.3 - добавить / заменить Windows-совместимые флаги состояния узла устройства https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/device-node-status-flags
3.4 - повторить подсистему инициализации
3.5 - повторить подсистему перечисления устройств
3.6 - повторить подсистему удаления устройства
3.7 - переделать подсистему работы с аппаратными ресурсами
3.8 - проанализировать и по возможности изменить подсистему интерфейса с подсистемой PnP пользовательского режима
3.9 - тестирование, отладка, форматирование кода
4 - PO manager;
Его можно назвать либо белым листом, либо черной дырой, текущая функциональность крайне минимальна, так как она не нужна виртуальным машинам, UNIMPLEMENTED - это намного больше, чем IMPLEMENTED ... требуется анализ и добавление необходимой функциональности, а также настройка процедуры выключения ОС.
5 - Drivers;
There are also problems with drivers: Test drivers compatibility between OS: Test NT drivers in ReactOS - https://docs.google.com/spreadsheets/d/1xvsjmEFZ9euM5uSlIDB3s1S_2xmgI7HtnHN22yZFfUw/htmlview# Test ROS drivers in NT OS - https://docs.google.com/spreadsheets/d/1xvsjmEFZ9euM5uSlIDB3s1S_2xmgI7HtnHN22yZFfUw/htmlview# Thanks to Andrey Shatalov for the table and everyone who filled it (column "Tested by")
5.1 - the arbiter library is required for the pcix driver, this driver should become the main instead of the current pci 5.2 - for the driver "acpi" it is necessary to achieve compatibility with NT, in particular, from DriverEntry (), make a call to HalInitPowerManagement () to create an interface with HAL.
How Basic Disks and Volumes Work - https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc739412(v=ws.10) 5.3 - add "drivers\storage\ftdisk.sys" 5.4 - add "drivers\storage\partmgr.sys"
5.5 - add missing functionality to NTFS, as well as the ability to boot the OS from NTFS partitions. ... CONTINUE ME
This is all for one purpose: making ReactOS not only an “OS for Virtual Box”.