ROS Kernel Roadmap Vgal — различия между версиями
(→5 - Drivers;) |
|||
| Строка 3: | Строка 3: | ||
==Roadmap ядра by Vgal == | ==Roadmap ядра by Vgal == | ||
| − | + | Сокращения: | |
| − | *MM - | + | *MM - менеджер памяти |
| − | *CC - | + | *CC - менеджер системного кэша |
| − | *PNP - | + | *PNP - менеджер включи-и-играй |
| − | *PO - менеджер | + | *PO - менеджер электропитания |
*HAL - Hardware Abstraction Layer | *HAL - Hardware Abstraction Layer | ||
| − | *ACPI | + | *ACPI — Advanced Configuration and Power Interface |
| − | *PIC | + | *PIC — Programmable Interrupt Controller |
| − | *APIC | + | *APIC — Advanced Programmable Interrupt Controller |
| − | *UP | + | *UP — Uniprocessor |
| − | *MP | + | *MP — Multiprocessor |
| − | + | Порядок разработки: | |
| + | Почему такой порядок? Кажется логичнее было бы начать с HALAACPI. Для полноценной разработки драйвера NTFS (основной файловой системы для NT-совместимых систем) необходим функционал CC, который в свою очередь исользует функционал разделов памяти MM. Таким образом это будет "зелёным светом светофора" для разработки NTFS. | ||
| − | + | ===1 - MM и СС менеджеры:=== | |
| + | Целесообразна совместная разработка, так как CC сильно зависит от MM. Btw: 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.3 - | + | |
1.1.4 - тестирование, отладка, форматирование кода | 1.1.4 - тестирование, отладка, форматирование кода | ||
| − | 1.2.1 - | + | 1.2.1 - СС менеджер, по-всей видимости, должен быть фактически обновлён, так использует другие структуры (оба - "cc" и "cache"). Пока у меня нет окончательного решения на этот момент. Анализ этой части пока не закончен. |
1.2.2 - тестирование, отладка, форматирование кода | 1.2.2 - тестирование, отладка, форматирование кода | ||
| − | 1.3.1 - на этом этапе должна быть реализована подкачка. Этот | + | 1.3.1 - на этом этапе должна быть реализована подкачка страниц. Этот этап может быть реализован позже. |
1.3.2 - тестирование, отладка, форматирование кода | 1.3.2 - тестирование, отладка, форматирование кода | ||
| Строка 44: | Строка 43: | ||
===2 - HAL=== | ===2 - HAL=== | ||
| − | + | Разработку вести в отдельных директориях "hal\halxxx\". Это позволит сконцентрировать усилия только на функционале и не отвлекаться на совмещении раличных версий (ускорение разработки). Также это более безопасно и не сломает другие HALs. RU http://vgal.ru.com/pic-ili-apic/ | |
| − | 2.1.1 - ACPI APIC UP HAL (halaacpi.dll) изменить и добавить | + | 2.1.1 - ACPI APIC UP HAL (halaacpi.dll) |
| + | изменить и добавить недостающий функционал для процессора и APIC контроллера. | ||
2.1.2 - тестирование, отладка, форматирование кода | 2.1.2 - тестирование, отладка, форматирование кода | ||
| − | 2.1.3 - после завершения разработки | + | 2.1.3 - после завершения разработки перевести "LiveCD" на halaacpi; |
| − | + | это можно разрабатывать после беты (или?): | |
2.3.1 - ACPI APIC MP HAL (halmacpi.dll) (нужна поддержка MP) | 2.3.1 - ACPI APIC MP HAL (halmacpi.dll) (нужна поддержка MP) | ||
| Строка 58: | Строка 58: | ||
2.2.1 - ACPI PIC HAL (halacpi.dll) | 2.2.1 - ACPI PIC HAL (halacpi.dll) | ||
| − | 2.4.1 - | + | 2.4.1 - Non-ACPI PIC HAL (hal.dll) |
| − | 2.5.1 - APIC UP HAL | + | 2.5.1 - Non-ACPI APIC UP HAL (halapic.dll) |
| − | 2.6.1 - APIC MP HAL | + | 2.6.1 - Non-ACPI APIC MP HAL (halmps.dll) |
| − | 2.7 - после | + | 2.7 - после окончания разработки объединить все HALs в один (если это будет необходимо). |
| − | ===3 - PNP | + | ===3 - PNP менеджер=== |
| − | + | Так как необходимо вносить существенные изменения, то разработку вести в параллельной директории "ntoskrnl\pnp_new\" (дополнительный ключ для Cmake - "PNP_NEW"). Это не сломает текущее ядро и будет более безопасно. | |
| − | 3.1 | + | 3.1 — добавить библиотеку arbiter; |
| − | 3.2 | + | 3.2 — скорректировать и дополнить библиотеку RTL "rangelist.c" (отсутствует поддержка пересекающихся диапазонов); |
| − | 3.3 - добавить | + | 3.3 - добавить\заменить Windows-совместимые Device Node Status Flags https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/device-node-status-flags |
| − | 3.4 - | + | 3.4 - переделать подсистему инициализации |
| − | 3.5 - | + | 3.5 - переделать подсистему нумерации устройств |
| − | 3.6 - | + | 3.6 - переделать подсистему удаления устройств |
3.7 - переделать подсистему работы с аппаратными ресурсами | 3.7 - переделать подсистему работы с аппаратными ресурсами | ||
| − | 3.8 - проанализировать и | + | 3.8 - проанализировать и возможно изменить подсистему интерфейса с User-mode PnP подсистемой |
3.9 - тестирование, отладка, форматирование кода | 3.9 - тестирование, отладка, форматирование кода | ||
| − | ===4 - PO | + | ===4 - PO менеджер;=== |
| − | + | Это можно назвать или белым листом или чёрной дырой :) | |
| + | |||
| + | Текущий функционал предельно минимален, так как для виртуальных машин он не обязателен, UNIMPLEMENTEDs гораздо больше чем IMPLEMENTED... Нужен анализ и добавление необходимого функционала, а также корректировка процедуры завершения работы ОС. | ||
===5 - Драйверы;=== | ===5 - Драйверы;=== | ||
| + | |||
| + | С драйверами также имеются проблемы: | ||
Также есть проблемы с драйверами: | Также есть проблемы с драйверами: | ||
| − | + | Проверка совместимости драйверов между ОС: | |
*Протестируйте драйверы NT в ReactOS - https://docs.google.com/spreadsheets/d/1xvsjmEFZ9euM5uSlIDB3s1S_2xmgI7HtnHN22yZFfUw/htmlview# | *Протестируйте драйверы NT в ReactOS - https://docs.google.com/spreadsheets/d/1xvsjmEFZ9euM5uSlIDB3s1S_2xmgI7HtnHN22yZFfUw/htmlview# | ||
*Протестируйте драйверы ROS в NT OS - https://docs.google.com/spreadsheets/d/1xvsjmEFZ9euM5uSlIDB3s1S_2xmgI7HtnHN22yZFfUw/htmlview# | *Протестируйте драйверы ROS в NT OS - https://docs.google.com/spreadsheets/d/1xvsjmEFZ9euM5uSlIDB3s1S_2xmgI7HtnHN22yZFfUw/htmlview# | ||
Версия 23:53, 1 июня 2021
https://jira.reactos.org/browse/CORE-16841
Содержание
[убрать]Roadmap ядра by Vgal
Сокращения:
- MM - менеджер памяти
- CC - менеджер системного кэша
- PNP - менеджер включи-и-играй
- PO - менеджер электропитания
- HAL - Hardware Abstraction Layer
- ACPI — Advanced Configuration and Power Interface
- PIC — Programmable Interrupt Controller
- APIC — Advanced Programmable Interrupt Controller
- UP — Uniprocessor
- MP — Multiprocessor
Порядок разработки:
Почему такой порядок? Кажется логичнее было бы начать с HALAACPI. Для полноценной разработки драйвера NTFS (основной файловой системы для NT-совместимых систем) необходим функционал CC, который в свою очередь исользует функционал разделов памяти MM. Таким образом это будет "зелёным светом светофора" для разработки NTFS.
1 - MM и СС менеджеры:
Целесообразна совместная разработка, так как CC сильно зависит от MM. Btw: 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" и "cache"). Пока у меня нет окончательного решения на этот момент. Анализ этой части пока не закончен.
1.2.2 - тестирование, отладка, форматирование кода
1.3.1 - на этом этапе должна быть реализована подкачка страниц. Этот этап может быть реализован позже.
1.3.2 - тестирование, отладка, форматирование кода
2 - HAL
Разработку вести в отдельных директориях "hal\halxxx\". Это позволит сконцентрировать усилия только на функционале и не отвлекаться на совмещении раличных версий (ускорение разработки). Также это более безопасно и не сломает другие HALs. 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;
это можно разрабатывать после беты (или?):
2.3.1 - ACPI APIC MP HAL (halmacpi.dll) (нужна поддержка MP)
2.2.1 - ACPI PIC HAL (halacpi.dll)
2.4.1 - Non-ACPI PIC HAL (hal.dll)
2.5.1 - Non-ACPI APIC UP HAL (halapic.dll)
2.6.1 - Non-ACPI APIC MP HAL (halmps.dll)
2.7 - после окончания разработки объединить все HALs в один (если это будет необходимо).
3 - PNP менеджер
Так как необходимо вносить существенные изменения, то разработку вести в параллельной директории "ntoskrnl\pnp_new\" (дополнительный ключ для Cmake - "PNP_NEW"). Это не сломает текущее ядро и будет более безопасно.
3.1 — добавить библиотеку arbiter;
3.2 — скорректировать и дополнить библиотеку RTL "rangelist.c" (отсутствует поддержка пересекающихся диапазонов);
3.3 - добавить\заменить Windows-совместимые Device Node Status Flags https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/device-node-status-flags
3.4 - переделать подсистему инициализации
3.5 - переделать подсистему нумерации устройств
3.6 - переделать подсистему удаления устройств
3.7 - переделать подсистему работы с аппаратными ресурсами
3.8 - проанализировать и возможно изменить подсистему интерфейса с User-mode PnP подсистемой
3.9 - тестирование, отладка, форматирование кода
4 - PO менеджер;
Это можно назвать или белым листом или чёрной дырой :)
Текущий функционал предельно минимален, так как для виртуальных машин он не обязателен, UNIMPLEMENTEDs гораздо больше чем IMPLEMENTED... Нужен анализ и добавление необходимого функционала, а также корректировка процедуры завершения работы ОС.
5 - Драйверы;
С драйверами также имеются проблемы:
Также есть проблемы с драйверами:
Проверка совместимости драйверов между ОС:
- Протестируйте драйверы NT в ReactOS - https://docs.google.com/spreadsheets/d/1xvsjmEFZ9euM5uSlIDB3s1S_2xmgI7HtnHN22yZFfUw/htmlview#
- Протестируйте драйверы ROS в NT OS - https://docs.google.com/spreadsheets/d/1xvsjmEFZ9euM5uSlIDB3s1S_2xmgI7HtnHN22yZFfUw/htmlview#
Спасибо Андрею Шаталову за таблицу и всем, кто ее заполнил (столбец «Проверено»)
5.1 - для драйвера pcix требуется arbiter-библиотека, этот драйвер должен стать основным вместо текущего pci
5.2 - для драйвера «acpi» необходимо добиться совместимости с NT, в частности, из DriverEntry () сделать вызов HalInitPowerManagement () для создания интерфейса с HAL.
Как работают базовые диски и тома - https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc739412(v=ws.10)
5.3 - добавить "drivers\storage\ftdisk.sys"
5.4 - добавить "drivers\storage\partmgr.sys"
5.5 - добавить недостающий функционал в NTFS, а также возможность загрузки ОС с разделов NTFS.
Все это сделано для одной цели: сделать ReactOS не только «ОС для Virtual Box».
