Эльбрус-3М

Только мне кажется не очень понятным как выполняется эмуляция x86 если брать преобразовывать по одной команде(наиболее универсальный метод) то при возможности выполнить 24 команды одновременно будет выполнять только одна и выполнение не более трёхсот миллионов операция - так не возможно обогнать 500 МГц PIII так как простейшие операции выполняются на нем на RISC ядре(1команда менее или равна 1 такт). Если динамически блоки бинарного кода преобразуются в код другой выполнимый на другой архитектуре - появляются проблемы разбора сложных ветвлений адрес перехода может быть вычислен косвенно и в новом коде распределение адресов сложно поддерживать(пример переход вычисляется по какой-то формуле и выполняется прибавлением результата к текущему адресу - решение удаление функции с заменой ее на таблицу переходов). Вторая проблема определения частей кода являющимися данными - они могут быть внутри исполнимого кода. В общем полиморфные вирусы могут не заработать:-).

Kernel space: E-paper support for Linux

Моё мнение относительно статьи о E-paper.

В статье предлагается использовать для управления 2 варианта решения проблемы отсутствия как такового буфера кадров кадров.

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

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

Современные тенденции развития операционных систем(Мое выступление)

Мой доклад на конференции в XAИ в 2006 году.
Плакаты были потеряны - остались лишь их упоминания.
Особая благодарность моему научному руководителю Дужему В. И.
за помощь в подготовке к конференции.

Плакат 1.

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

• Скорость реакции на изменения в аппаратной архитектуре и концепциях.
• Удобство использования ( администратора системы для сервера или конечного пользователя для офисного или домашнего компьютера).

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

Плакат 2.

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

Плакат 3.

На данный момент существует 2 базовых архитектуры ядра и 3 вида архитектур, которые можно назвать дальнейшим расширением этих архитектур.

Базовые (классические):

• Микроядро;
• Монолитное ядро.

Потомки:

• Экзоядро (похоже на микроядро) ;
• Модульное (похоже на монолитное);
• Гибридное ядро (монолитное плюс модульное).

Плакат 4.

Среди ядер можно выделить следующие проблемы:

1. Неэффективное использование ресурсов из-за не эффективного и не оптимизированного под архитектуру кода, и как следствие невозможности добавления новых возможностей без полной переработки архитектуры системы;
2. Сложность внесения исправлений и изменений вследствие сложной архитектуры системы;
3. Отставание от развития аппаратуры вследствие большого объема изменений требуемых для добавления поддержки или нежелания разработчиков аппаратуры и операционной системы распространять информацию о разработанной или разрабатываемой системе;
4. Для внесения новых возможностей требуется значительное изменение архитектуры системы вследствие того, что разработчики не заложили возможность расширения системы.

Плакат 5.

На плакате 5 рассмотрены основные особенности существующих операционных систем.

Плакат 6.

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

Плакат 7.

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

Плакат 8.

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

Плакат 9.

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

Плакат 10+11.

Гибридное ядро в отличие от предыдущего является расширением монолитного и модульного ядра с использованием абстракции от оборудования. Основная идея: если что-то можно перенести в пространство ядра для повышения скорости, почему бы не перенести? Что привело к новым недостаткам размер ядра большие затраты из-за абстракции от оборудования(хотя не все разработчики драйверов соблюдают эту идею). И из-за работы некоторых частей в ядре системы возникают проблемы безопасности в системе (некоторые частям не требуется такой большой приоритет, но они работают в ядре). Эти проблемы переносятся и в другие системы(LINUX и ATI+NVIDIA).

Плакат 12.

Более оптимальный вариант это объединение всех достоинств ранее рассмотренных систем. Основное единство интерфейсов на всех уровнях. В результате система разделена на две части у одной есть сквозной интерфейс для всех уровней, а у второй предназначен только для пользовательских программ, он аналогичен POSIX или подобному интерфейсу. В результате системные программы драйвера и другие программы могут запускаться на всех 3 уровнях (системный уровень, уровень ядра, уровень пользователя). И базовая часть ядра будет представлять экзоядро с поддержкой этого интерфейса. В результате появляется возможность в зависимости от задач переносить части с уровня на уровень.

Плакат 13.

Выводы:

• Большинство современных операционных систем не поддерживает возможности расширения и увеличения надежности в зависимости от настроек системы и запуска приложений в изолированном пространстве.
• В дальнейшее направление исследований изучить возможность модернизации существующих операционных систем в направлении изменения архитектуры ядра и улучшения его характеристик.
• Наиболее подходящими для усовершенствования являются системы c открытыми кодами и лицензией подобной GPL(LINUX,*BSD).

Исследование алгоритмов взаимодействия параллельных процессов

В.И.Дужий, ст.преп;Д.В.Паук, студент
Национальный аэрокосмический университет им. Н.Е.Жуковского "ХАИ"
ИКТМ'2005

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

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

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

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