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

IMHO пользовательский интерфейс - другой уровень абстракции. До него еще надо дойти.

О защищенности системы - надо продумать механиз привилегий и ограницений каждого объекта. Можно конечно сделать по аналогии с *nix группы пользователей и к каждому объекту пускать только тех, кто разрешен. Но IMHO недостаточная гибкость получается.


Вообще о системе - надо продумать уровни, объект и их иерархию. Тогда все вопросы( о ПП, ПИ, ИПИ) решаться сами.

З.Ы. Лично я полностью запутался, что каждый хочет в ПИ и ИПИ. Может тогда картинками иерархию этих уровней, объектов с интерфейсами.

Цитата rcz, 12.09.03, 14:23:27

О защищенности системы - надо продумать механиз привилегий и ограницений каждого объекта. Можно конечно сделать по аналогии с *nix группы пользователей и к каждому объекту пускать только тех, кто разрешен. Но IMHO недостаточная гибкость получается.

Думаю, правильного управления ключами будет достаточно. Полагаю, что проблема, из-за которой ФС не м.б. реализована через ключи, не так уж и серьёзна. Если хорошо всё продумать, то она вообще исчезнет.

Надеюсь на выходных составить подробную спецификацию.

Идеи ключей и объектов, естественно, очень древние. И наверняка было много попыток реализовать под них ОС.
В описании KeyKOS очень много общего. Но некоторых моментов там не нашел:
- иерахрическая структура ключа,
- однозначное соответствие ключа и интерфейса, связь между потомками ключа и наследованием,
- виртуализация.

Для последней идеи пока никто не указал прецедента реализации, поэтому ее пока можно считать концептуально новой.

Цитата Vilmor, 12.09.03, 12:08:45

Угу. Там много чего интересного. Не всё оттуда для нас годится, но и там высказывается мысль, что всё аппаратное I/O прячется от посторонних в режим ядра (типа HAL). Конечно же, не это там главное... Внимательно читая, узнаещь много интересного. Например, вполне оправданный отказ от очередей сообщений и механизм RETURNа.

Насчет механизма RETURN я не очень понял их идею. Навскидку это похоже на какие-то "обратные" сообщения.. Но я изначально предлагал в каждом Send- и RunMessage возвращать ответ.

Отказ от очередей сообщений заслуживает внимания.
Это означает ровно то, что из предлагавшихся трех типов сообщений (Post, Send, Run) остается только RunMessage.
Возможно, на это стоит пойти, так как в том же Windows без PostMessage не прекрасно, но вполне обходятся.

Цитата

Но в KeyKOS в одном процессе может сидеть только один объект, а если надо больше - то это уже другой уровень абстракций, которого там нет

И не нужно распыляться по уровням.
Давайте разберемся с уровнем ядра, где подобъектов нет.

Цитата Vilmor, 12.09.03, 13:57:33

Грубая аналогия: мы линкуем программу с библиотеками. Даже если мы никогда не используем ни одной ф-ции из библиотеки, но в программе где-то есть ссылка на неё, библиотека обязательно прилинкуется, даже если это и не нужно. Вот вам и зависимость.

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

Цитата

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

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

Цитата

Думаю. правильнее было бы сказать, что ПП может использовать ИПИ, а может и не использовать. Но знать оно должно всегда, если, конечно мы не собираемся делать 2 разных варианта ОС. А поскольку ПП будет обязан всегда знать об ИПИ, то мы будем обязаны с каждой новой версией ИПИ исправлять код в ПП.

Исправлять не придется. По аналогии с естественным языком: не всем нужно его знать в объеме словаря Даля, Эллочка для своих целей обойдется 10-ю словами, и "перекомпилировать" ее не нужно при появлении новых слов в языке, так как ей они не нужны.

Не вижу причин отказываться от очередей сообщений. Получатся только еще большие ограничения по функциональности - о Асинхронных сообщениях и в/в придется забыть.

Цитата rcz, 12.09.03, 16:49:10

Не вижу причин отказываться от очередей сообщений. Получатся только еще большие ограничения по функциональности - о Асинхронных сообщениях и в/в придется забыть.

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

2nvm: чтобы не засорять тред, предлагаю вопрос о ПП обсудить в частной переписке. Разумеется, если у вас ещё осталось желание слушать мои доводы

Сообщение отредактировано: vilmor - 12.09.03, 13:18

позволю цитату.

Цитата

A FORK invocation leaves the invoking domain in the running state.

A CALL leaves the invoking domain in the waiting state and automatically generates within the message, as the last key, a resume key to the invoking domain. The invoking domain remains in the waiting state until the resume key is invoked, whereupon the domain returns to the running state. Resume keys exist only to waiting domains, and as a resume key is invoked, all resume keys to the designated domain disappear and are everywhere efficiently replaced by null keys, q.v.

A RETURN invocation leaves the invoking domain in the available state. If there are domains that were queued by the unavailability of the RETURNing domain, one is promptly run.

FORK - есть асинхронный вызов. Но если сделать срузу несколько FORK. Не получится, что мы их потеряем?

IMHO на нижнем уровне все сведется к очередям по приоритетам.

Или если Domain сам будет их выстраивать в очереди - не очень хорошо получится, когда будут выполняться несколько Domainов.

Цитата

Если приложению надо, то оно само может создать такую очередь

В итоге каждый драйвер будет реализовывать одно и то же.

Сообщение отредактировано: rcz - 12.09.03, 13:27

Как я вижу выполнение запроса.
Делается RunMessage( Message{key="/root/obj/subobj/method","/root/SourceObj",MessageCode,data});
Далее ядро просматривает свои ключи и ищет объект  subobj  (можно отправляя по всей иерархии с root до subobj).
В очередь этого объекта выстраивается мессадж. Если вызов синхронный - вызываемый объект засыпает, ждет ответа, асли асинхронный- остается в запущенном состоянии.

Приходит время планировщика, и если приоритет этого сообщения в данный момент наивысший, вызывается method с параметром data. (любой размер, только надо его предварительно перенести в это адресное пространство)

Планировщик запускается при каждом входе в ядро и прерывании.

Сообщение отредактировано: rcz - 12.09.03, 13:47

Ответ приходит аналогично. (Надо только установить еще что-то вроде ID сообщения для опознания)

Цитата rcz, 12.09.03, 17:26:39

FORK - есть асинхронный вызов. Но если сделать срузу несколько FORK. Не получится, что мы их потеряем?

Цитата оттуда же:

Цитата

If a running domain tries to invoke a start key to a domain that is not available, the running domain is queued along with other domains invoking start keys to the unavailable domain. They will run again when the designated domain becomes available

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

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

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

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

Цитата rcz, 12.09.03, 17:26:39

IMHO на нижнем уровне все сведется к очередям по приоритетам.

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

Цитата rcz, 12.09.03, 17:26:39

Или если Domain сам будет их выстраивать в очереди - не очень хорошо получится, когда будут выполняться несколько Domainов.

Не понял ???

Цитата rcz, 12.09.03, 17:26:39

В итоге каждый драйвер будет реализовывать одно и то же.

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

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

Сообщение отредактировано: vilmor - 12.09.03, 14:03

Цитата

Или если Domain сам будет их выстраивать в очереди - не очень хорошо получится, когда будут выполняться несколько Domainов.

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

Все ж не вижу преимущества этого способа отправки сообщений.

Цитата

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

Надо учитывать, что они работают в разных адресных пространствах. Бес syscallов не получится. Все равно сообщения пройдут через ядро.

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

Цитата rcz, 12.09.03, 18:18:18

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

Я же говорю: пул.
Т.е. максимум N тредов в домене. N м.б. разным, в т.ч. =1.
И если единственный тред будет задан, то - добро пожаловать в очередь на обработку. Но при этом мы сами распределяем по приоритетам, так, как кам надо!

Я сильно подозреваю, что внутренняя реализация COM для Local Server и Remote Server именно такая. Во всяком случае, должна быть очень похожа.

Цитата rcz, 12.09.03, 18:18:18

Надо учитывать, что они работают в разных адресных пространствах. Бес syscallов не получится. Все равно сообщения пройдут через ядро.

а) syscall - для сообщения объекту уровня ядра;
б) вызов ф-ции - для объекта в том же домене, т.е. в том же адресном пространстве. Здесь syscall не нужен.

Цитата

Я же говорю: пул.
Т.е. максимум N тредов в домене. N м.б. разным, в т.ч. =1.
И если единственный тред будет задан, то - добро пожаловать в очередь на обработку. Но при этом мы сами распределяем по приоритетам, так, как кам надо!

А я говорю, что если несколько доменов, то сообщения между ними никак не регулируются.

Цитата

б) вызов ф-ции - для объекта в том же домене, т.е. в том же адресном пространстве. Здесь syscall не нужен.

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

Сообщение отредактировано: rcz - 12.09.03, 14:36

Цитата rcz, 12.09.03, 18:20:40

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

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

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