Разработка концептуально новой ОС

Цитата Vilmor, 10.09.03, 15:30:29

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

Приходилось читать о компиляторах Явы, выдающих код, не уступающий C++. Не для JVM, конечно. Да бог с ней с Явой. Тем более, я ее как раз не люблю. Но есть Оберон,  Эйфель, Cyclone, которые предназначены для написания системного ПО. Самое смешное - даже Фортран куда надежнее Си.

Цитата rcz, 10.09.03, 15:13:10

Syscall  - переключаться придется. Но Системных вызовов не должно быть много - в основном только отправка сообщений системе. Все вызовы получаться в виде сообщений к разным объектам. (Правда здесь пострадает производительность. Сообщения в системе - RPC.)

Я считаю, что результат декомпозиции посылки сообщения от пользовательского объекта ядрёному - это и есть syscall. На большинстве платформ это - аналог "INT n"

Например, если мы выводим текст на локальную консоль, то syscall делает это сам (передавая управление объекту консоли), а если консоль удалённая, то syscall передаёт запрос через RPC или по др. протоколу.

Цитата rcz, 10.09.03, 15:13:10

Никогда не нравились IRQL в NT. И страничные ошибки в ядре должны быть предусмотрены. (Не нужны лишние BSOD,).  Тему свопа надо очень подробно рассмотреть.

IRQL как раз и вводится для предотвращения BSOD - чтобы в момент обработки первого страничного исключения не возникало второе. BSOD - следствие злостного игнорирования IRQL. В Linux IRQL нет, потому что он не нужен - там действительно при каждом syscallе происходит переключение в пространство ядра и системе приходится самой вручную проверять каждую подозрительную страницу, если надо взять данные из процесса или скопировать их обратно. Естественно, вё это замедляет работу.

Моя идея в том, чтобы допустить х.б. 2 уровня - первый, когда возможны страничные сбои, второй - нет. В первом система оказывается сразу после начала syscallа, а во втором - после соответствующей исключительной ситуации. Таким образом, 90\% syscallов не потребуют переключения в адресное пространство ядра и проверки доступности и прав на страницы, что должно заметно ускорит работу, сильно упростит систему и при этом (imho) не повредит "красоте" её архитектуры.

Почему не потребуется переключение адресного пространства? Потому что всё, что нужно процессу от ядра, можно отобразить в область адресного пространства процесса.

Цитата rcz, 10.09.03, 15:13:10

Если сегментов нет - стандартная FLAT модель памяти. (Но если с сегментами - создать дескрипторы юзерских сегментов. Чтоб у них память была с 0.N и в Ядро с 0..N).

Обеими руками - за FLAT-модель! У меня есть идеи, как её эффективно использовать.

Цитата rcz, 10.09.03, 15:13:10

Память ядра (виртуальная)... Так удобно сделать при инициализации.(Прямое отображение физического на виртуальное пр-во).
0x00000000 - нет
0x00001000 - для BIOS, DMA и т.п
0x00400000 - ядро
0x00500000 - каталог страниц и таблицы страниц
0x01000000 - ХИП
0x6fffffffffff - стек ядра  // пустые страницы, для оршанизации PF при ошибке стека.
0x70000000 - видеопамять и т.п.
0x80000000 - USER. (Если б был сегменты - можно сделать, чтоб они сюда указывали).
Получается как у всех осей. Но можно в сделать, чтобы кождая задача имела свой каталог страниц( хотя не знаю, поддерживается ли это не x86 процессорами). Без сегментов у всех процессов одно виртуальное адресное пространство.

Каждой программе желательно иметь свой каталог страниц для своего адресного простанства, и на большинстве платформ это возможно.

Но WinCE этого не делает, даже если не поддерживаются сегменты. Вместо этого, всё в одном адресном пространстве, которое поделено на 32 равных части. Поэтому м.б. запущено максимум 32 процесса.

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

Я предлагаю другую схему:

Первые 2Гб процесса - прикладной программе, для её кода, данных и стека.
Ещё 0.5-1Гб - для проецирования DLL. За счёт этого для разных процессов одна и та же DLL одинаково проfixupлена, знчит не тратится память на отдельные копии её кода для каждого процесса. Оставшиеся 1-1.5Гб - для ядра, и имеет две зоны. Первая - для локальных данных процесса, которые нужны ядру. Вторая зона одинакова для всех процессов на локальной машине (если она в кластере), и туда отображается I/O видеокарты и прочих локальных устройств - в том числе и для обработки IRQ в контексте любого процесса. Поскольку дисковой кэш м.б. очень большим, то для доступа к нему может оказаться удобнее переключаться в адресное пространство ядра, которое аналогично предложенному вами.

Недоступные страницы могут быть в любой из зон, и если система работает при высоком IRQL, то она обязана проверять их.

Цитата rcz, 10.09.03, 15:13:10

Загрузка.
Микроядерность. Главное загрузиться в память. Инициализировать подсистему В/В и объектов. Должен быть какой-то map, что от куда потом грузить. Загрузить эти объекты(они сами знают что потом делать. почти Plug'n'Play). Загрузить первую задачу. Далее задачи что-то пытаются использовать. При запросе ресурса ФС это подгружает.

Обычно загрузчик отвечает за формирование таблицы размещения физической памяти.
На КПК обычно загрузчик и ОС записаны на флэшку. При ресете управление попадает к загрузчику, который копирует образ ОС в RAM и запускает его, передавая некоторые параметры. В образе ОС находится не только ядро, но и статически прилинкованные модули и все драйвера устройств. Plug'n'Play и PCI на КПК не бывает. BIOSа тоже нет.

ЗЫ: интересно обратить внимание, как самоинициализируются статически прилинкованные модули в Linux. При линковке сама собой формируется таблица указателей на их процедуры инициализации/клеанапа.

Цитата rcz, 10.09.03, 15:13:10

Компиллятор лучше gcc. (g++ для объектов, но как их совместить?.). Наследование и прочее ООП придется в начале делать руками. (А множественное и виртуальные методы ?). Всю систему объектов надо придумать(новая технология типа COM).

Об использовании C++ и STL при прогр-ии ядра ОС много говорилось в ньюсгруппе alt.os.development. Высказывались самые различные мнения. Стоит заметить, что для этого надо ещё приспособить libstdc++, и вообще, прогрммирование на C++ с STL скрывает узкие места в коде - виртуальные методы и RTTI скорости не прибавляют, а она там ох как нужна. К тому же, для С++ существует проблема стандартизации языка. Это значит, что если где-то не будет g++, то прийдётся попотеть, чтобы адаптировать код для др. компилятора. А для некоторых "бедных" платформ C++ м.б. вообще недоступен. Так что я бы пока остановился на чистом Си.

Цитата rcz, 10.09.03, 15:13:10

Всегда приходится чем-то жертвовать. Главной жертвой системы получается производительность(хотя сейчас все железо ускорилось и даже DX теперь весь на COM). Но главный плюс объектности - гибкость. Нужно еще подумать и о надежности такой  системы.

Я считаю, что драйверы режима ядра должны предоставлять ОО-интерфейс, но надо, чтобы и традиционные, не ОО-программы, могли иметь доступ к ним через syscallы.

Кстати, если планируется делать что-то вроде DX, то большая часть его должна работать опять же на уровне приложения. В ядре - только набор ф-ций, которые не могут быть эффективно реализованы вне его. Например, аппаратная отрисовка графических примитивов - реализуется драйвером видеокарты в режиме ядра. Такой драйвер так же обязательно должен поддерживать отсечение фигуры по произвольной области и преобразование координат. Это будет особенно критично для оконной системы, поскольку нельзя позволить пользовательской программе рисовать прямо в видеобуфер - иначе она сможет затирать или перерисовывать другие окна, делать свои окна невидимыми, что идёт вразрез системе безопасности.

Цитата rcz, 10.09.03, 15:13:10

О платформе - думаю пора переходить на 64 разряда.

Ожидается, что 64-битные платформы очень долго будут популярны только на серверных платформах, но не на PC, и уж точно не в MP3-плеерах и КПК.

Цитата Trurl, 10.09.03, 16:31:07

Приходилось читать о компиляторах Явы, выдающих код, не уступающий C++. Не для JVM, конечно. Да бог с ней с Явой. Тем более, я ее как раз не люблю. Но есть Оберон,  Эйфель, Cyclone, которые предназначены для написания системного ПО. Самое смешное - даже Фортран куда надежнее Си.

Эйфелю научиться, чтоль... :

Цитата

Как обеспечить время отклика, если в любой момент может потребоваться обращение к диску? Можно сделать её опциональной как предлагает Vilmor.

Решается простым отключением свопа.

Цитата Trurl, 10.09.03, 16:28:41

Угу. Как обеспечить время отклика, если в любой момент может потребоваться обращение к диску? Можно сделать её опциональной как предлагает Vilmor.

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

Интересно, что мы сказали одно и то же совершенно независимо друг от друга

Цитата

Я считаю, что драйверы режима ядра должны предоставлять ОО-интерфейс, но надо, чтобы и традиционные, не ОО-программы, могли иметь доступ к ним через syscallы.

syscall - интерфейс. Я так понял, система изначально задумавалась как ОО. не-ОО программ ведь не будет. (Хотя это ОО получается просто условно. Просто есть некоторые интерфейсы, иерархия и сообщения).

С памятью прояснили(В общих чертах.суть одна, цифры разные). И 32 бит - 4 Гб.

языки ядра
boot - ессесно asm - (GNU as или NASM).
ядро - С. - gcc.
далее - может понадобится писать свой компиллер (можно создать язык Ре-бемоль) и/или линкер.

Остается теперь всю архитектуру расписать (С чего бы начать). Картиночки порисовать.


Теперь многозадачность... где-то описывал суть. Теперь структуры. (Си)
struct task{
    TSS * //состояние - регистры. CR3 - свой каталог страниц
    MessageQueue  //очередь сообщений
    VM *      // страницы  задачи. Память
   ...
}
switch_to_task(){ //RING0
   Загрузка страниц.
   //попытка доставить сообщение.
   переключение (с загрузкой TSS) на обработчик сообщения. (Хм.. при обычном переключении(голодающий процесс) нет обработчика).
  //если это обработка сообщения - TSS должен быть другим.
}
switcher(){ //RING0
  for_each_task поиск задачи с сообщением большего приоритета.
  switch_to_task();//если нет сообщений вообще - IDLE. Точнее Idle - Task у которого в очереди всегда сообщение с наинизшим приоритетом.
}

shedule(){ // может быть в RING3. Реализация нескольких алкоритмов планировки.
 //пересчет приоритетов и времени исполнения
 //Кто голодал - сообщение, что должно выполниться.
 switcher() // как-то когда-то оно вызывается.
}
Приоритет "голодающего" сообщения < прерываний и системных.

Это в общем.

Цитата rcz, 10.09.03, 18:30:02

syscall - интерфейс. Я так понял, система изначально задумавалась как ОО. не-ОО программ ведь не будет. (Хотя это ОО получается просто условно. Просто есть некоторые интерфейсы, иерархия и сообщения).

Пускай так. Надо будет тщательно всё это проработать, чтобы накладные расходы были минимальны.

Я сейчас просмотрел выложенную спецификацию.
В общем, нравится, но требует мелких исправлений.
Например, нужно разрешать доступ к аппаратному I/O только из драйверов режима ядра. Прочие драйверы могут осуществлять I/O только через другие драйверы, которые им доступны. Это не вредит основной концепции ОС, и устраняет множество проблем.

Собираюсь написать свою спецификацию. Она будет почти во всём повторять существующую, за исключением некоторых деталей, и дополнительно будет содержать мои идеи. К сожалению, это будет не так скоро, как мне хотелось бы – сказывается нехватка времени.

Цитата rcz, 10.09.03, 18:30:02

boot - ессесно asm - (GNU as или NASM).

Бутсектор – асм. Остальное – Си.

Цитата rcz, 10.09.03, 18:30:02

Остается теперь всю архитектуру расписать (С чего бы начать). Картиночки порисовать.


Теперь многозадачность... где-то описывал суть. Теперь структуры. (Си)
struct task{
    TSS * //состояние - регистры. CR3 - свой каталог страниц
    MessageQueue  //очередь сообщений
    VM *      // страницы  задачи. Память
   ...
}
switch_to_task(){ //RING0
   Загрузка страниц.
   //попытка доставить сообщение.
   переключение (с загрузкой TSS) на обработчик сообщения. (Хм.. при обычном переключении(голодающий процесс) нет обработчика).
  //если это обработка сообщения - TSS должен быть другим.
}
switcher(){ //RING0
  for_each_task поиск задачи с сообщением большего приоритета.
  switch_to_task();//если нет сообщений вообще - IDLE. Точнее Idle - Task у которого в очереди всегда сообщение с наинизшим приоритетом.
}

shedule(){ // может быть в RING3. Реализация нескольких алкоритмов планировки.
 //пересчет приоритетов и времени исполнения
 //Кто голодал - сообщение, что должно выполниться.
 switcher() // как-то когда-то оно вызывается.
}
Приоритет "голодающего" сообщения < прерываний и системных.

Это в общем.

Долгая тема для обсуждения. На этот счёт у меня есть идеи (и не только свои собственные), некоторые из которых уже были опробованы на практике. Но не сейчас, не здесь...

Цитата Shaman, 10.09.03, 09:58:50

Диалог FileSave??? handle??? открытый на запись???
Тоесть - все действия будут производится только с дискрипторами? И при любых других действиях тоже? А консоль?
Мне даже лень перечислять причины, по которым это (скажу мягко) затруднительно и опасно одновременно ;D

Объясню подробнее (в предыдущем посте была только "голая" идея, без деталей реализации).
У ОСи нет глаз и ушей, ей плевать кто сидит за терминалом и есть ли вообще терминал. С точки зрения системы пользователь - это просто некоторое приложение, назовем его представителем пользователя (ПП).
И логинится в систему именно ПП, а вовсе не сам пользователь, который лишь подсказывает пароль.
ПП может работать и без реального пользователя, но когда пользователь сидит за терминалом, то ключи от драйверов консоли, GUI, DirectX, клавы и пр. передаются во владение ПП.
(В прошлом посте я не развел понятия ПП и драйверов, поэтому и выглядело дико).

Теперь повтор идеи.

ОС должна быть такой, чтобы вирусов в ней не было. Не было в том смысле, что вирусы бы не могли распространяться по своей инициативе, а только с разрешения пользователя (если пользователь сам хочет запустить вирус, то это его право - но тогда это не вирус).
Ядро предполагается минимальное, поэтому добиться отсутствия дыр в нем - задача реальная.
Главные сервисные приложения, которые поставляются в дистрибутиве ОС, - тоже возможно вычистить.
Остаются прикладные программы - в них были, есть и, пока стоит мир, будут дыры. И пока существует Интернет будут браузеры, запускающие червей.
Отсюда единственное решение: прикладная программа НЕ ДОЛЖНА получать прав пользователя (разве что часть).
Но приложению нужно сохранять документы в каталоге пользователя, на который оно не имеет прав.
Поэтому оно должно обратиться к ПП, который через драйвер консоли или GUI, спрашивает у пользователя имя файла, затем сам открывает файл и передает его прикладной программе.

Таким образом, из FileSave приходит все же путь - а handle появляется на следующем уровне.

Если у кого-то есть лучшие идеи для исключения вирусов - то интересно послушать. Но ИМХО предложенная мера практически вынужденная, и в том или ином виде абсолютно необходима.

Идея драйверов в режиме ядра все же мне сильно не нравится.
Дело в том, что лишние полномочия - это всегда ОЧЕНЬ плохо!
А полномочия ядра для драйвера не просто не нужны - они ему просто не в тему.
Режим ядра предназначен для РАСПРЕДЕЛЕНИЯ ресурсов между потребителями. А драйвер использует только выделенные ему ресурсы - и очень нежелательно ему иметь потенциальный доступ к чужим. Если на такое приходится идти, то это техническая недоработка архитектуры. Но нехорошо в вопросах принципиального дизайна идти на поводу технических проблем.

Предлагаю изначально в рабочий проект не включать категорию драйверов режима ядра.
Но в качестве альтернативы включить в интерфейс ядра функцию прямой установки уровня привилегий процессора (естественно, что для ее вызова нужен ключ root).
Это даст возможность при необходимости добавить такие драйверы, не меняя ничего в дизайне (они стартуют как обычные, но потом сами повышают режим).

Организационное предложение: сосредоточиться на проектировании ядра. В идеале ядро должно получиться гибким и универсальным - что на него можно будет при желании навесить хоть Unix, хоть Windows, или продолжать разрабатывать концептуально новые компоненты.

ИМХО, еще рано обсуждать структуру и детали реализации ядра, пока не спроектирован и не утвержден его интерфейс, то есть набор функций ядра и оперируемые величины (handles, сообщения и т.п.).

Сообщение отредактировано: nvm - 10.09.03, 17:30

А какие недостатки у BC_3.11 в качестве компилятора ядра?
Я не работал с gcc, поэтому в bc вижу только преимущества  ;):
- сносная IDE,
- DOS грузится быстрее Linux, что для отладки немаловажно  ;D,
- из реального режима легко "прыгнуть" в защищенный.. и если повезет - даже вернуться и продолжить работу (чего не получится под Linux).

Цитата nvm, 10.09.03, 19:51:45

Идея драйверов в режиме ядра все же мне сильно не нравится.
Дело в том, что лишние полномочия - это всегда ОЧЕНЬ плохо!
А полномочия ядра для драйвера не просто не нужны - они ему просто не в тему.
Режим ядра предназначен для РАСПРЕДЕЛЕНИЯ ресурсов между потребителями. А драйвер использует только выделенные ему ресурсы - и очень нежелательно ему иметь потенциальный доступ к чужим. Если на такое приходится идти, то это техническая недоработка архитектуры. Но нехорошо в вопросах принципиального дизайна идти на поводу технических проблем.

дело в том, что в режиме пользователя адресное пространство драйвера будет доступно любому приложению, имея доступ, скажем к драйверу HDD, можно залесть в любой файл и получить "лишние полномочия", а "это всегда ОЧЕНЬ плохо!"

Цитата

Идея драйверов в режиме ядра все же мне сильно не нравится.
Дело в том, что лишние полномочия - это всегда ОЧЕНЬ плохо!
А полномочия ядра для драйвера не просто не нужны - они ему просто не в тему.
Режим ядра предназначен для РАСПРЕДЕЛЕНИЯ ресурсов между потребителями. А драйвер использует только выделенные ему ресурсы - и очень нежелательно ему иметь потенциальный доступ к чужим. Если на такое приходится идти, то это техническая недоработка архитектуры. Но нехорошо в вопросах принципиального дизайна идти на поводу технических проблем.

Вся проблемма, что драйверам необходим непосредственный доступ к аппаратному. Но надо это минимизировать. Как уже писал, за подгрузку драйверов отвечает ФС. Она же распределяет ресурсы. А проблемма з защитой может только быть, если разрешить пользователям загружать свои драйвера или оставить дыру для проникновения в RING0.

Цитата

Если у кого-то есть лучшие идеи для исключения вирусов - то интересно послушать. Но ИМХО предложенная мера практически вынужденная, и в том или ином виде абсолютно необходима.

(Эх.. Зачем так со зверями? А как же работа антивирусников ? . )
Это сложный вопрос. Главное пока не наделать дыр в ядре и ...драйверах, их общении с системой, RPC.

Цитата

Отсюда единственное решение: прикладная программа НЕ ДОЛЖНА получать прав пользователя (разве что часть).
Но приложению нужно сохранять документы в каталоге пользователя, на который оно не имеет прав.
Поэтому оно должно обратиться к ПП, который через драйвер консоли или GUI, спрашивает у пользователя имя файла, затем сам открывает файл и передает его прикладной программе.

Получается, что ему при сохранении файла придется постоянно набирать пароль. Мне его жалко. А систему прав приложения над хорошо обдумать. Найти золотую середину между безопасностью и удобством.

О защите - будем сертифицироваться по A1 (будем первыми, надеюсь). .  

Преимущества gcc
1) кроссплатформенный (под ДОС тоже есть)
2)Очень гибкий.

BC делает объекты, которые с другими линкерами не пойдут, а tlink не сделает нормального образа системы.
Редактор - любой текстовый, с подсветкой синтаксиса. Все что угодно.

Поэтому ставьте LINUX для gcc (Или в Windows ставьте DJGPP,или MinGw). Виртуальную машину (мне нравится VMWare).

А о перепрыгиванияв в защищенный режим - лчуше сделать сразу с бутом и тестировать, загружая в VMWare (или другую виртуальную машину).

Вобщем делаем спецификацию, уточняем все, добавляем новые идеи, исправляем старые.

Цитата

дело в том, что в режиме пользователя адресное пространство драйвера будет доступно любому приложению, имея доступ, скажем к драйверу HDD, можно залесть в любой файл и получить "лишние полномочия", а "это всегда ОЧЕНЬ плохо!"

Очень веский аргумент. Ведь этот драйвер сможет запустить каждый. Соответственно даже фальшивку.