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

[rcz]

Отлично. Об объектах.

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

Посылать сообщения можно и объекту разделяемой памяти. Только обработчик будет другой.
Хэндлы - содержаться в адресном промтранстве. Т.е. в процессе.

У каждого объекта будет ACL.
Это в идеале объектная ориентированность.

Объект процесс можно сделать как объект, содержащий потоки и память.

З.Ы. Немного утопично. Но это настоящее ОО.

[nvm]

Цитата rcz, 25.09.03, 17:52:44

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

Это в идеале объектная ориентированность.
З.Ы. Немного утопично. Но это настоящее ОО.

Не то, чтобы это утопично - просто неадекватно.
Это будет не настоящее ОО, а ОО, доведенная до абсурда.

Зачем делать объектами то, что ими по смыслу не является?!
Это как на одном острове из зверей людей делали.. без особого, впрочем, успеха..

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

А поток даже и в абсурде не может быть объектом, потому что это ДЕЙСТВИЕ (обращение к объекту) - как вызов функции.

Пусть объектами будет не что попало, а только настоящие объекты - это и будет настоящее ООП.

Без ключа (хотя бы безымянного) объектов быть не должно.

[rcz]

Может и правда. Но по сути. Посмотрите. Все, что я перечислил, в WIN 2k/XP сделано объектами. Притом могут быть именованными (в нашем случае считай ключ).

Просто обращение сообщениями в целях оптимизации не будет. Хотя это не нарушало бы концепцию этой ОС.

И потоки тоже объекты. Притом более вожные чем процессы.

Сообщение отредактировано: rcz - 25.09.03, 15:56

[nvm]

Это как поток может быть объектом, если это действие??? Тогда ходьба - тоже объект?
Объект в каком-то смысле содержит в себе потоки.
Даже в MFC объект CThread - не есть поток, а только содержит "в себе" поток, но методы этого объекта могут вызываться из других потоков. Поэтому даже объект CThread нельзя полностью отождествить с одним потоком.

Если бы ограничиться только сообщениями типа Post/SendMessage - тогда объект действительно бы однозначно ассоциировался с потоком цикла обработки сообщений в нем, и можно было бы сказать, что это одно и тоже.
Но, когда есть Run/ForkMessage - тогда через любой объект могут проходить разные потоки и однозначной связи нет.

[nvm]

Насчет отладки.
Значительную часть ОС можно отладить через эмуляцию под виндами.

Нельзя так отладить лишь часть ядра, осуществляющую управление памятью (физически: страницами и сегментами) и драйвера низкого уровня.

Зато можно вполне отладить все остальное:
- управление памятью (указателями) в самом ядре,
- механизм ключей,
- потоки и сообщения,
- драйвер файловой системы,
- оболочку над Unix-приложениями,
- все утилиты.

А первую часть ядра, видимо, придется отлаживать через дампы и вычитывание кода.

Думаю, стоит начать работу именно со второй части.

[rcz]

Цитата

Это как поток может быть объектом, если это действие Тогда ходьба - тоже объект?
Объект в каком-то смысле содержит в себе потоки.

Поток как объект содержит в себе
1) состояние регистров - контекст. При переключении на новый поток, они загружаются
2) приоритет.
3) права.
* В Linux содержит еще и карту памяти.
4) много еще, чего не учли.

+ к тому же вспомним, что в ОСях можно управлять потоками. Если это не объект, то управлять им не получится.

Поток - это не действие. Тогда уж скорее описание действий.

У нас разные понятия о потоке.

Цитата

Думаю, стоит начать работу именно со второй части.

Логично.
Но надо будет быть уверенными, что делаем переносимый код.

[nvm]

Давайте определимся в терминах.
Конечно, объектом можно назвать почти, что угодно.
Но в смысле ООП объектом является сущность, любое действие с которой осуществляется через интерфейс методов.
В этом смысле, потоки объектами не являются. Хотя структура данных им и соответствуют.

Я бы предложил называть объектами только обработчики ключей. Хотя это сугубо терминологический вопрос - назови хоть горшком..

Цитата rcz, 26.09.03, 00:10:02

Поток как объект содержит в себе
1) состояние регистров - контекст. При переключении на новый поток, они загружаются
2) приоритет.
3) права.
* В Linux содержит еще и карту памяти.
4) много еще, чего не учли.

1,2) Содержит. И еще, поток содержит собственный стек.
3) Права относятся только к процессу в целом - внутри все права одинаковы (делать иначе - странно, так как у процесса одно адресное пространство, доступное всем его объектам).

Цитата

+ к тому же вспомним, что в ОСях можно управлять потоками. Если это не объект, то управлять им не получится.

Да, это важный момент, упущенный в спецификации.
Нужно, чтобы функция ForkMessage, котрая единственная создает потоки, возвращала хэндл нового потока.
Соответственно, нужно добавить функции изменения приоритета потока и принудительного завершения.

[rcz]

Цитата

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

действия - запустить, остановить, завершить. Поэтому это уже объект, как бы его не называли.

И, считаю, что они тоже должны иметь ключи и им можно отправлять сообщения.

Цитата

3) Права относятся только к процессу в целом - внутри все права одинаковы (делать иначе - странно, так как у процесса одно адресное пространство, доступное всем его объектам).

Думаю и потоки тоже должны иметь права. Иначе получится (процесс ведь не исполняется) что один поток потребует права, и они появятся у всех. (Хотя это не принципиально, но может лучше разделить права. Так же как и приоритет.)

Сообщение отредактировано: rcz - 26.09.03, 15:37

[nvm]

Цитата rcz, 26.09.03, 19:36:46

действия - запустить, остановить, завершить. Поэтому это уже объект, как бы его не называли.

Настоящий объект САМ выполняет действия над собой - а если действия производятся извне, да еще "без его ведома", то это не объект с точки зрения ООП.

Цитата

И, считаю, что они тоже должны иметь ключи и им можно отправлять сообщения.

Так они их и так имеют...
То есть имеют ключи объекты, и сообщения посылаются объектам - но обрабатываются сообщения исключительно потоками, которые на этих объектах крутятся.

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

Агент - основной элемент системы.
Это единственный объект, который может совершать действия, и к которому можно адресовать сообщения.

Цитата

Думаю и потоки тоже должны иметь права. Иначе получится (процесс ведь не исполняется) что один поток потребует права, и они появятся у всех. (Хотя это не принципиально, но может лучше разделить права. Так же как и приоритет.)

Приоритет они могут устанавливать друг другу.

Адресное пространство - это тоже разновидность прав. И в целях единообразия лучше все права связывать с процессом.
Если два потока могут свободно залазить в данные друг друга, то какой смысл между ними делить права?

[rcz]

1)

Цитата

Настоящий объект САМ выполняет действия над собой - а если действия производятся извне, да еще "без его ведома", то это не объект с точки зрения ООП.

Вспоминая потоки в Jave. Программный поток наследует предопределенный абстрактный класс thread.

Запуск - что-то вроде thread.run.
На низком уровне примерно выгрядит как
object thread{
   run();
};
при вызове

thread::run(){
}
вызывается такая ф-ция

void __thiscall run(register *this){
    //его запуск
}.
Т.е. методы объекта - функции, который первым параметром указатель на структуру, содержащую их поля.
Поэтому никакой объект не выполняет действия над собой.

Это я называю объектом. И поток под это понятие попадает.

Цитата

Адресное пространство - это тоже разновидность прав. И в целях единообразия лучше все права связывать с процессом.
Если два потока могут свободно залазить в данные друг друга, то какой смысл между ними делить права?

То же самое ведь и при использовании shared memory, но не заприщать же ее наличие. Они могут обращаться и к другим объектам, а если процесс захочет запустить поток от лица другого пользователя.  

А таблицы хэндлов - обычно во всех осях они могут наследоваться, а могут и нет. Т.е. у каждого потока появляется своя таблица хэндлов.

[nvm]

Цитата rcz, 26.09.03, 21:53:26

1)
Т.е. методы объекта - функции, который первым параметром указатель на структуру, содержащую их поля.
Поэтому никакой объект не выполняет действия над собой.

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

[nvm]

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

По реализации.

Чтобы решить, что какими средствами делать и отлаживать, желательно разработать общую структуру.

Положим, что все ядро работает с отключенной трансляцией адресов.

В ядре получается три основных блока:
- менеджер памяти (страниц, серментов),
- менеджер кучи ядра,
- функции верхнего уровня.

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

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

[rcz]

Цитата

Терминологический спор - бесполезное занятие  
Давайте придерживаться определений, которые введены раньше: понятия потока и процесса введены в спецификации, и не корректно их менять. А объекты я не вводил, поэтому согласен на любое ваше определение, лишь бы оно было определенным..

Это не спор. Понятие потока, процесса в спецификации подроюного нет.
А я, видимо, опять скатился к взгляду на эту проблему со стороны реализации.

Цитата

Положим, что все ядро работает с отключенной трансляцией адресов.

Можно уже сразу включить страничную трансляцию адресов

Цитата

В ядре получается три основных блока:
- менеджер памяти (страниц, серментов),
- менеджер кучи ядра,
- функции верхнего уровня.

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

Даже при включенной страничной адресации код ядра будет располагаться "физически непрерывным целым куском". Хотя двигать в физической памяти уже не будет необходимости.

Все остальное остается справедливым.

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

[nvm]

Цитата rcz, 29.09.03, 11:24:53

Это не спор. Понятие потока, процесса в спецификации подроюного нет.
А я, видимо, опять скатился к взгляду на эту проблему со стороны реализации.

Сначала бы разобраться с дизайном на верхнем уровне абстракции...

Цитата

Можно уже сразу включить страничную трансляцию адресов

Это спорная идея. Как минимум, получим лишнее переключение задач - внутри ядра. То есть все syscall-ы, требующие управления памятью, повлекут не одно, а два переключения задач.
И, мне кажется, получится слишком головоломный дизайн у ядра при включенном преобразовании..

Цитата

Даже при включенной страничной адресации код ядра будет располагаться "физически непрерывным целым куском". Хотя двигать в физической памяти уже не будет необходимости.

Это он будет ВИРТУАЛЬНО непрерывным куском, а физически - разрывным.

Цитата

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

А что вы где-то в-тихую обсуждаете? Нельзя ли посвятить в курс дела?!

[rcz]

Цитата

Это спорная идея. Как минимум, получим лишнее переключение задач - внутри ядра. То есть все syscall-ы, требующие управления памятью, повлекут не одно, а два переключения задач.
И, мне кажется, получится слишком головоломный дизайн у ядра при включенном преобразовании..

1)Делать ядро без страничной адресации ??? Или под "трансляцией адресов" понимается что-то другое ?

Нет. Страничную адресацию в ядре стоит включить. Не выключать/включать же ее при каждом переключении задач. Тем более на ее поддержку в ядре не будет издержек.

Только другой вопрос - все ли можно будет выкидывать в своп файл? Будет диапазон неподкачиваемой памяти.

2) что значит "получим лишнее переключение задач - внутри ядра. То есть все syscall-ы, требующие управления памятью, повлекут не одно, а два переключения задач. " ? Из-за чего ?

Цитата

Это он будет ВИРТУАЛЬНО непрерывным куском, а физически - разрывным

Да. только микроядро будет непрерывным куском. А делее все модули будет динамическими.. Но в физической памяти располагаться после ядра.

Цитата

А что вы где-то в-тихую обсуждаете? Нельзя ли посвятить в курс дела?!

Это где-то здесь уже обсуждалось.
Потом некоторые уточнения делались с Vilmor'ом, до его исчезновения. (Сюда не кидали, потому что это имеет малое отношение к концепции и архитектуре ОС)
Структура памяти готова (потребуются некоторые уточнения) , но я сейчас не дома, и сюда отправить не могу.