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

Цитата

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

А почему бы и нет?

Цитата

Кстати, кольца есть опять же только на x86. Конечно, на др. процах есть их аналоги, но не прямые. Во всяком случае, м. рассчитывать только на 2 "кольца"   кольцо для ядра ОС и кольцо для приложений.

Про "кольца" - это для красного словца. Выделяем им адресное пространство и пущай там забавляются.

Цитата

2) Все программы всегда представляют собой =объекты - DLL,COM. Как будут дергаться интерфейсы? Может нужно только для GUI.

Интерфейсы дергаются компилятором, а потом проверяются загрузчиком.

Цитата

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

Цитата

Вы имеете в виду Just-In-Time (JIT) компиляцию? Это как в .NET? Да, это хорошая вещь для интерпретируемых языков. Если простой интерпретатор выполняет программу раз в 20-30 медленнее аналога на Си, то JIT-машина делает это только в 2-3 раза медленнее, но всё же это слишком, чтобы всю ОС переводить на JIT.

Имеется в виду не только виртуальная машина. И даже не JIT компиляция как в .NET. Скорее как в Juice: back-end компилятора встраивается в загрузчик. Генерируется полноценный код. Кстати, он может быть оптимизирован под конкретную машину.

Цитата

6) Сборщик мусора... В виртуальной машине хорошо. В бинарнике (ядро тоже бинарное) - не получится. Да и сборка мусора произойдет при удалении адресного пространства приложения.

А если у нас нет адресного пространства приложения? Да и приложений никаких нет.

Цитата

Дело в том, что сборка мусора - вещь весьма трудоёмкая. Если у вас тысячи объектов и сотни тысяч ссылок, то это выливается уже в большую проблему?.
Кроме того, ОС, которая навязывает использование сборщика мусора, не м. считаться real-time OS, т.е. не м. быть использована для целого класса задач.
IMHO, разумное решение - сделать сборщик опциональной фичей, которая работает не на уровне ядра, а на прикладном уровне, в приложениях, которые в этом нуждаются.

Если у нас тысячи объектов и сотни тысяч ссылок, то это уже большая проблема. Как раз в таких случаях доктора прописывают сборку мусора.
Насчет real-time согласен. Но если делать real-time от многого придётся отказаться.

Цитата

7) Т.е. машина возобновляет работу на том же месте, где остановилась?

Это было бы слишком уж хорошо. По крайней мере, хотелось бы, чтобы документы не пропадали. Заодно избавиться от File/Save.

Цитата

Наверное, я просто не вкурсе этого вопроса. Где можно прочитать что-то конкретное про Active Objects? Сайт http://bluebottle.ethz.ch в этом отношении мне показался совершенно не информативным. Было бы интересно узнать, какие при этом накладные расходы, и вообще узнать бы побольше об этой технологии...

Кроме ethz ничего посоветовать не могу. Но там вся полезная информация - в pdf.
Самое лучшее - диссертация Мюллера "The Active Object System Design and Multiprocessor Implementation".

Все ж не соглашусь с ОСью на виртуальной машине. Потеря производительности значительная (если код именно интерпретируется). Если компилируется ... Смысл бинарной совместимости немного теряется. Все равно придется писать компилляторы под разные платформы. Достатачна переносимость на уровне исходников.

Если ядро работает в виртуальной машина, зачем же тогда реализовывать загрузчик. Пишешь все на яве. Реализовываешь все, что было сказано. Получаешь большой апплет. И - ОС в эксплорере.(видел эмулятор ВЫНь на флеше, тоже ведь ОСь)

Цитата

Про "кольца" - это для красного словца. Выделяем им адресное пространство и пущай там забавляются.

     Разделение, основаное на страничной адресации + сегментация.
     А если вообще надо разделить(отделить от оборудования), может вообще написать эмулятор (типа VMWare).

Цитата Vilmor, 09.09.03, 10:26:04

Я не совсем понял, что вы имеете в виду: разрешить _любому_ приложению доступ ко _всем_ I/O-портам и IRQ, которые не заняты другими приложениями?

И вообще, ребята, не серьёзно всё это. Если так всё делать, будет уже куча проблем. Вы ведь хотите, чтобы это работало не только на x86? Тогда вам надо всё делать не так. Вы бы почитали сначала доки по процессорам семейств IA32, IA64, ARM, ALPHA! Например, у RISC-процессоров, в отличие от x86, нет портов ввода-вывода, а значит, и нет никакой битовой карты, которая, к тому же, и неэффективна на практике.

ИМХО, надежность важнее эффективности. Поэтому если нет БКВВ, то стоит пойти на то, что драйверы будут обращаться к портам косвенно - через вызовы функций ядра. Все равно массивной прокачки данных через порты не бывает.

Цитата

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

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

Цитата leemouse, 09.09.03, 16:15:38

Кхе-кхе... Ну кто же занимается подготовкой проекта в ФОРУМЕ. Хотя бы конфу какую нить зарегили штоли. А ещё лучше отдельный сайт с чатом, CVS - репозитарием и т.д. Определиться наконец с составом оргкомитета и выложить хотя бы базовые соглашения и протоколы.

На данный момент Исходники не обладают такими возможностями, но изискания в этом направлении ведутся

Постараюсь упростить жизнь проекта на форуме, как смогу

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

"The GNU Hurd is the GNU project's replacement for the Unix kernel. The Hurd is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels (such as Linux)."

"GNU Hurd это альтернативная GNU разработка Unix ядра. Hurd организован как семейство сервисов, работающих на Mach микроядре. Сервисы представляют: файловую систему, сетевые протоколы, контроль доступа к файлам и другие особенности операционной системы, присутствующие в Unix ядре или в схожих ядрах (таких, как Linux)"

От себя: Хурд - ИМХО - самая удачная попытка объединить преимущества новейших подходов к дизайну операционных систем.

Так вот. А что если сделать (по крайней мере попытатся) что-то в этом же духе - подменить ядрышко у UNIX'а? (Или присоединиться к этому проекту?) Таким образом - наследуется почти весь существующий софт Unix'а.

Цитата rcz, 09.09.03, 00:08:54

Но к некоторым портам возможен доступ из нескольких драйверов.

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

Цитата

С прерываниями проще.
Реализация. Драйвер требует права на прерывание. Регистрируется. Как только происходит прерывание, посылается сообщение приложению-драйверу.  Тут стоит задуматься о том, собирается ли эта система быть Real Time.

Да, посылается сообщение, но не простое, а RunMessage - с созданием новой нити в пространстве драйвера.
Приоритеты прерываний после этого не нужны, а достаточны приоритетов потоков.

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

Цитата

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

Если уж делать сегменты, то в каждой задаче свои и много.

Цитата

И последнее. Средства программирования. Это будет gcc,g++ или свой концептуально новый компиллятор и язык?

До этого еще далеко... Да хоть BC_3.11..
Очевидно, что компилятор нужен готовый. А язык - вряд ли есть альтернативы C++.

Цитата Shaman, 09.09.03, 21:08:36

От себя: Хурд - ИМХО - самая удачная попытка объединить преимущества новейших подходов к дизайну операционных систем.

Возможно. Но это не новая система, а просто версия UNIX.

Цитата

Так вот. А что если сделать (по крайней мере попытатся) что-то в этом же духе - подменить ядрышко у UNIX'а? (Или присоединиться к этому проекту?) Таким образом - наследуется почти весь существующий софт Unix'а.

Для этого есть тред про "дистрибутив Linux".. Если и не совсем для этого, то тот тред все равно ближе.

Все таки не стоит подменять цель - это будет тогда совсем другой проект.

Но насчет наследования софта UNIX мысль крайне важная.
Для хоть каких-то шансов к жизнеспособности ОС обязана поддерживать приложения Windows или Linux (лучше - "и"). Но так как на реализацию WinAPI вряд ли у кого хватит пороху, то остается Linux.
Только проектировать ОС нужно, не ориентируясь специально на Unix, а уже по готовности системы дописать shell для Linux-приложений.

Цитата rcz, 09.09.03, 14:42:18

1) По предложенной nvm архитектуре это (безъядерная архитектура) получается.

Не безъядерная, а микроядерная. Уж ядро-то совсем не похоже на приложение.
А приложения, хоть и однаковы по структуре и режиму процессора, но далеко не "равны": каждому сопоставлен ключ, а ключи образуют жесткую иерахрию.

Цитата

4) О виртуальной машине. Всегда всем хотелось свободы. Поэтому надо сказать да и бинарникам, и виртуальной машине. Ядро само поймет как какое приложение исполнять.

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

Цитата nvm, 09.09.03, 21:59:39

Возможно. Но это не новая система, а просто версия UNIX.
Для этого есть тред про "дистрибутив Linux".. Если и не совсем для этого, то тот тред все равно ближе.

Совсем не для этого
Там никто не пытается переделать ядро системы.
Что такое подмена ядра?
Есть (например) Mach ядро (микроядро). Переписывается именно оно + (!) существующие драйвера для базовах устройств. ИМХО - драйвер - это такой же софт. При переносе драйвера с одной платформы на другую всегда имеется крос-платформенная часть, которую никто не трогает. При упомянутом мною подходе можно будет двигаться итеративно - создать перечень устройств, которые должны быть на 100\% поддержаны первой версией ОС. Отталкиваясь от Mach ядра создать усечённую версию UNIX. Переделывать по капле те его составляющие, которые мешают спокойно спать, не забывая менять при этом базовый набор драйверов (и описывать, как это дОлжно делать, для последывателей).

Это всё моё ИМХО, на самом деле ОСей я никогда не писал и не знаю как это делается на самом деле ;D

драйвера я ессно писал и переносил

Иллюстрация, как могут работать изложенные идеи.

Понятие пользователя в системе локализовано в пределах приложения – менеджера пользователей (таких приложений может быть несколько). Пользователь представлен именем, паролем и списком доступных ключей.
Всем пользовательским интерфейсом в системе управляет специальное приложение–драйвер (GUI), и пользователь напрямую общается только с ним.
Это приложение «во всем слушается» пользователя, но изначально не имеет никаких прав. Для регистрации пользователь сообщает ему логин, который пересылается менеджеру, который презентует в GUI соответствующие ключи.
Пример работы GUI.
Обычное приложение в среднем имеет права доступа на запись только в одну папку на диске. Пусть это будет Интернет-браузер. Предположим он получил от пользователя команду сохранить документ. Прав на запись в нужную папку он не имеет. Но в любом случае он должен обратиться к GUI с заданием вывести диалог FileSave. В качестве результата будет получено не имя файла, а handle, уже открытый на запись!
Такая технология позволяет избежать наличия у приложений лишних прав. Тот же Интернет-браузер может теперь смело запускать любые вирусы (хоть exe, хоть макро). Худшее, что те смогут сделать – стереть кэш скачанных файлов.

Подозреваю, что под Unix идеология существенно другая, и заменой ядра не обойтись..

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

Ну уж нет! ;D ;D ;D

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

В любом случае - не обижайтесь

Сообщение отредактировано: Shaman - 10.09.03, 05:59

Цитата

Всегда всем хотелось свободы.

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

Цитата nvm, 09.09.03, 23:27:08

Подозреваю, что под Unix идеология существенно другая, и заменой ядра не обойтись..

Естественно!!! Главное поддержка стандартов: posix, например
QNX, например - не Юникс, но Юникс совместимая ОС.

Цитата

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

Здесь я имел в виду.
Далее модуль=объект.
Ядро микроядерное. При загрузке подключаются модули, отвечающие за исполнение файлов. Как только приходит запрос на исполнение чего-либо(загрузки объекта), ядро выбирает ответственный за данный формат модуль. Этот же модуль можно сделать как исполняемую среду (в случае виртуальной машины). Само ядро не знает форматы, но она знает модули, ответственные за них.

Цитата

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

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

Цитата

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

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

И еще надо определиться с терминологией.Объект, Ядро, ФС ,модуль, Приложение.
Объект - некая сущность  в системе.
Ядро - главный, порождающий объект( хотя привязан сильно к низкомы уровню и инициализирует саму объектность).
ФС(файловая система) - хранилище всех ресурсов. Некий менеджер объектов-ресурсов.
Драйвер - объект, отвечающий за  аппаратный ресурс. Регистрируется в файловой системе и получает от нее сообщения.
Приложение - совокупность объектов пользователя (процесса). Исполняется
Модуль - часть приложения. (объект).
Сообщения - способ "общения" объектов. Запросы/ответы. Синхронный/асинхронные Только родителей с детьми.


Где-то бред. Просто уже начинаю запутываться что есть что. (Может уже справочник создавать.)
Архитектура уже проясняется и довольно отчетливо. Только собрать бы все в кучу(точнее по разделам  boot/ mem/  fs/ shedule/ modules/ IPC/ user/). Так удобней было бы править.

Сообщение отредактировано: rcz - 10.09.03, 09:02