API for OS

[crazy-mike]

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

Я хотел - чтобы функции вообще не вызывались , а создавалась и выполнялась "сопрограмма" в системе команд ВМ юзера (почти как канальная программа в System 360). :grum:
И пусть себе виртуально мутирует в виртуальном времени ...:grum:

[Sixteen]

Я хотел - чтобы функции вообще не вызывались , а создавалась и выполнялась "сопрограмма" в системе команд ВМ юзера (почти как канальная программа в System 360). :grum:
И пусть себе виртуально мутирует в виртуальном времени ...:grum:

а што такое сопственно вм юзера если не бальшой и толстый майкрокернел?

[crazy-mike]

а што такое сопственно вм юзера если не бальшой и толстый майкрокернел?

Под VM/VSE - "теоретически" как бы и так. Но вся шиза в том - что все равно надо было делать SVC 202 - а это неправильно из-за нарушения control flow. :grum:
Верх кайфа - когда внутри "user objects space" вообще не надо (формально)обращаться к любой из разновидностей OS API calls. :grum:

[crazy-mike]

Интересно - автора темы мы еще не совсем напугали? :grum:

[algoritm]

А тебя низкоуровневый или высокоуровневый интерфейс интересует?

Любой :cheer:

[algoritm]

"В идеале" - его вообще не должно быть (с точки зрения "security").
:grum:Нет API - вирусы труднее писать.
Но тут есть ещё один идиотизм - что должно "юзать кеш-память" : OS или application?
А OS API ко всему прочему ещё и снижает производительность системы. Даже в случае передачи параметров через регистры - в эти самые регистры нужно ещё и загнать значения по одной команде mov на регистр и потом ещё выполнить "системный вызов" (SVC,emt,int,syscall - и т.д. ).
Даже просто call - это "медленно". Тем более - что всё это выполняется "очень часто".
Наверное могло бы существовать два вызова "API init" и "API end".
По apiInit - проверялись бы "полномочия пользователя" и создавалась бы его ВМ (в зависимости от "прав пользователя". При этом они бы не имели ничего общего с правами юзеров OS ) для OS API (со своей системой команд , адресным пространством и memory mapping). И вся эта хрень бы загружалась в кеш-память и оставалась бы там до выполнения apiEnd.
А "функции API" бы в этом случае существовали в виде команд одноадесной или даже безадресной виртуальной машины.
:grum: Ну и весь "сеанс" бы выполнялся как отдельный process (с notification messages для application). User Application в этом случае работало бы только с OS data view - а не с реальными OS data и практически никогда не могло бы их "испортить".

То есть API в том числе должен обеспечивать возможность security :?: :cheer:

[algoritm]

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

То есть чтобы API в том числе мог включать новый код в состав сервиса :?: :cheer:

[crazy-mike]

То есть API в том числе должен обеспечивать возможность security :?: :cheer:

API в "классическом виде" вообще не должно быть - для обеспечения security и сохранеия работоспособности системы.
Но реализация этого концепта в моноядерных и микроядерных системах - существенно различается.
Кстати - по этомоу поводу таки можно вспомнить Automotive RTOS. :grum:

[algoritm]

Под монитором виртуальных машин - как раз к этому и сводится. Но я постил немного о другом - об оптимизации последовательностей "системных вызовов" (и привел самый варварский пример возможности реализации такой хреновины - хотя у IBM на AS/400 много всего и покруче было).
:grum:

То есть чтобы API мог эффективно использовать функции сервиса :?: :cheer:

[crazy-mike]

То есть чтобы API в том числе мог включать новый код в состав сервиса :?: :cheer:

Нет.
Все частично сводилось к dynamic create application environement.
И даже здесь приложение лишено возможности "юзать API" в классическом смысле.