ROS Kernel Roadmap Vgal — различия между версиями

Материал из Русский WINE
Перейти к: навигация, поиск
(→‎3 - PNP manager)
 
(не показаны 3 промежуточные версии этого же участника)
Строка 3: Строка 3:
  
 
==Roadmap ядра by Vgal ==
 
==Roadmap ядра by Vgal ==
−
Аббреаиатуры:
+
Сокращения:
  
−
*MM - диспетчер памяти
+
*MM - менеджер памяти
−
*CC - диспетчер системного кэша
+
*CC - менеджер системного кэша
−
*PNP - диспетчер plug and play
+
*PNP - менеджер plug and play
−
*PO - менеджер питания
+
*PO - менеджер электропитания
  
 
*HAL - Hardware Abstraction Layer
 
*HAL - Hardware Abstraction Layer
−
*ACPI - Advanced Configuration and Power Interface
+
*ACPI — Advanced Configuration and Power Interface
−
*PIC - Programmable Interrupt Controller
+
*PIC — Programmable Interrupt Controller
−
*APIC - Advanced Programmable Interrupt Controller
+
*APIC — Advanced Programmable Interrupt Controller
−
*UP - Uniprocessor
+
*UP — Uniprocessor
−
*MP - Multiprocessor
+
*MP — Multiprocessor
  
−
Очередность разработки:
+
Порядок разработки:
  
 +
Почему такой порядок? Кажется логичнее было бы начать с HALAACPI. Для полноценной разработки драйвера NTFS (основной файловой системы для NT-совместимых систем) необходим функционал CC, который в свою очередь исользует функционал разделов памяти MM. Таким образом это будет "зелёным светом светофора" для разработки NTFS.
  
−
Почему такая очередь? Логичнее начать с HAL. Для полной реализации драйвера 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 - диспетчеры MM и CC===
+
1.1.1 - основная задача на этом этапе - это избавление от _MEMORY_AREA, использование структур _SECTION и _SEGMENT вместо PROS_SECTION_OBJECT и _MM_SECTION_SEGMENT. Соответственно код для поддержки работы секций необходимо будет изменить и добавить отсутствующую функциональность.
  
−
Рекомендуется совместная разработка, так как CC сильно зависит от MM. Кстати: https://reactos.org/blogs/memory-manager-development/, поскольку необходимо внести значительные изменения, а структуры разделов несовместимы, разработка должна выполняться в параллельных каталогах "ntoskrnl\mm_new\" и "ntoskrnl\cache_new\" (дополнительный ключ для Cmake -"MM_CC_NEW"). Это не повредит текущее ядро ​​и будет безопаснее.
+
1.1.2 - добавление инициализации системного кэша и недостающих функций для него.
  
−
1.1.1 - основная задача на этом этапе - избавиться от _MEMORY_AREA, используя структуры _SECTION и _SEGMENT вместо PROS_SECTION_OBJECT и _MM_SECTION_SEGMENT. Соответственно, необходимо будет изменить код для поддержки работы секций и добавить недостающую функциональность.
+
1.1.3 - коррекция MmAccessFault() и всех связанных функций
−
 
+
−
1.1.2 - добавление инициализации системного кеша и недостающих функций для него.
+
−
 
+
−
1.1.3 - исправление MmAccessFault () и всех связанных функций
+
  
 
1.1.4 - тестирование, отладка, форматирование кода
 
1.1.4 - тестирование, отладка, форматирование кода
  
−
1.2.1 - диспетчер CC, видимо, должен быть реально обновлен, поэтому он использует другие структуры (обе - «cc» и «cache»). Пока у меня нет окончательного решения. Анализ этой части еще не завершен.
+
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 \". Это позволит сосредоточить усилия только на функциональности и не отвлекаться на совмещение разных версий (ускорение разработки). Это также более безопасно и не нарушит работу других HAL. RU http://vgal.ru.com/pic-ili-apic/  
+
Разработку вести в отдельных директориях "hal\halxxx\". Это позволит сконцентрировать усилия только на функционале и не отвлекаться на совмещении раличных версий (ускорение разработки). Также это более безопасно и не сломает другие HALs. RU http://vgal.ru.com/pic-ili-apic/
  
−
2.1.1 - ACPI APIC UP HAL (halaacpi.dll) изменить и добавить недостающую функциональность для процессора и контроллера APIC.
+
2.1.1 - ACPI APIC UP HAL (halaacpi.dll)
 +
изменить и добавить недостающий функционал для процессора и APIC контроллера.
  
 
2.1.2 - тестирование, отладка, форматирование кода
 
2.1.2 - тестирование, отладка, форматирование кода
  
−
2.1.3 - после завершения разработки использовать в "LiveCD" "halaacpi" вместо "hal"
+
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 - HAL PIC без ACPI (hal.dll)
+
2.4.1 - Non-ACPI PIC HAL (hal.dll)
  
−
2.5.1 - APIC UP HAL без ACPI (halapic.dll)
+
2.5.1 - Non-ACPI APIC UP HAL (halapic.dll)
  
−
2.6.1 - APIC MP HAL без ACPI (halmps.dll)
+
2.6.1 - Non-ACPI APIC MP HAL (halmps.dll)
  
−
2.7 - после завершения разработки объединить все HAL в один (при необходимости).
+
2.7 - после окончания разработки объединить все HALs в один (если это будет необходимо).
  
−
===3 - PNP manager===
+
===3 - PNP менеджер===
  
−
Поскольку необходимо внести существенные изменения, разработка должна выполняться в параллельном каталоге «ntoskrnl \ pnp_new \» (дополнительный ключ для Cmake - «PNP_NEW»). Это не повредит текущее ядро ​​и будет безопаснее.
+
Так как необходимо вносить существенные изменения, то разработку вести в параллельной директории "ntoskrnl\pnp_new\" (дополнительный ключ для Cmake - "PNP_NEW"). Это не сломает текущее ядро и будет более безопасно.
  
−
3.1 - добавить arbiter-библиотеку;
+
3.1 — добавить библиотеку arbiter;
  
−
3.2 - настроить и дополнить RTL библиотеку "rangelist.c";
+
3.2 — скорректировать и дополнить библиотеку RTL "rangelist.c" (отсутствует поддержка пересекающихся диапазонов);
  
−
3.3 - добавить / заменить Windows-совместимые флаги состояния узла устройства https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/device-node-status-flags
+
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 - проанализировать и по возможности изменить подсистему интерфейса с подсистемой PnP пользовательского режима
+
3.8 - проанализировать и возможно изменить подсистему интерфейса с User-mode PnP подсистемой
  
 
3.9 - тестирование, отладка, форматирование кода
 
3.9 - тестирование, отладка, форматирование кода
  
−
===4 - PO manager;===
+
===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#
 +
 
 +
Спасибо Андрею Шаталову за таблицу и всем, кто ее заполнил (столбец «Проверено»)
  
−
it can be called either a white sheet or a black hole
+
5.1 - для драйвера pcix требуется arbiter-библиотека, этот драйвер должен стать основным вместо текущего pci
−
the current functionality is extremely minimal, since it is not necessary for virtual machines, UNIMPLEMENTEDs are much more than IMPLEMENTED ...
+
−
need analysis and adding the necessary functionality, as well as adjusting the OS shutdown procedure.
+
  
−
===5 - Drivers;===
+
5.2 - для драйвера «acpi» необходимо добиться совместимости с NT, в частности, из DriverEntry () сделать вызов HalInitPowerManagement () для создания интерфейса с HAL.
  
−
There are also problems with drivers:
+
Как работают базовые диски и тома - https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc739412(v=ws.10)
−
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.3 - добавить "drivers\storage\ftdisk.sys"
−
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.4 - добавить "drivers\storage\partmgr.sys"
−
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.
+
5.5 - добавить недостающий функционал в NTFS, а также возможность загрузки ОС с разделов NTFS.
−
...
+
−
CONTINUE ME
+
  
−
This is all for one purpose: making ReactOS not only an “OS for Virtual Box”.
+
Все это сделано для одной цели: сделать ReactOS не только «ОС для Virtual Box».  
 
{{ReactOS}}
 
{{ReactOS}}

Текущая версия на 23:53, 1 июня 2021

Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

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

Порядок разработки:

Почему такой порядок? Кажется логичнее было бы начать с 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 - Драйверы;

С драйверами также имеются проблемы:

Также есть проблемы с драйверами:

Проверка совместимости драйверов между ОС:

Спасибо Андрею Шаталову за таблицу и всем, кто ее заполнил (столбец «Проверено»)

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».

ReactOS
Search.png
Доклады
О ReactOS • ARWINSS • ЧеЗа
Информация Новости Выпуски новостей • Переводы блогов • Новости проекта • Видео • ReactOS на Хабре • USB от Вадима Галянта
Разработка Руководство по программированию • Отсутствующая функциональность • Ветви разработки • Компоненты системы • ReactOS и Wine • План работ • Roadmap ядра by Vgal • Разработчики • Совместимость с dll Windows • Наиболее значимые изменения за год • Используемые проекты • Google Summer of Code • Известные проблемы
Порты AMD64 • ARM • Xbox • PowerPC
Компоненты Файловые системы • Режим совместимости • Отчеты об ошибках • Печать • USB • Ядро
Загрузчик Восстановление MBR • Загрузка из GRUB • Параметры загрузки
Прочее ARWINSS • Приложения в ReactOS • Оформление ReactOS • Координаторы • "Пасхальные яйца" • Монетизация
Другое Типы ядер • FreeWin95
Помощь
RAM-диск ReactOS по PXE • с жесткого диска
Разработка Стиль написания кода • Стандарты RC-файлов • Работа с документацией • Венгерская нотация • GNU Indent • [ Subversion : ветви • слияние • использование TortoiseSVN ] • Основы перевода • Отправка патчей
Репорты Отладка в VirtualBox • Отладка на экран • Добавление программы в менеджер приложений • Отправка отчетов
Отладка Com0com • GDB • Kdbg • Rossym.gdb • Roswin.gdb • WinDBG • Руководство по WinDBG • Включение трассировки ядра • Коды DPRINT • Удалённый отладчик ReactOS
Сборка CMake • RBuild • Файлы RBuild • Автоматическое копирование файлов • Сборка MINGW-w64 • Сборка модулей • Среда сборки
Тестирование VirtualBox • VMware • QEMU • Hyper-V • Необходимый объём диска • Перенос файлов на виртуальный диск • Установка ReactOS • Установка драйверов
Сеть Общие папки • Samba • NFS
Игры Установка DirectPlay
Обновление ReactOS • Загрузочная флешка • Чем можно помочь проекту • Создание нового пользователя • Звук и сеть в VirtualBox • Съемка и публикация видео • IRC-канал • Сторонние компоненты • FAQ • ReactOS как рабочая станция • ReactOS и UEFI
Обзоры Оболочка • NTVDM • WOW • Community Edition • История сайта • ReactOS Server • Криптография • ПО времен XP
Источник — «http://winehq.org.ru/index.php?title=ROS_Kernel_Roadmap_Vgal&oldid=6031»