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

хм... ну если ты видел codenull.net то собственно для написания ОС. полноценной. и приследую две цели. первая конечно для себя(учиться/опыт), вторая - создать конкуретноспособный продукт, причём бесплатный и построенный по современным технологиям!=)
офф. А ты?=)
_____--
кстати, на том же codenull.net в раздкле документация английская валяется прекрасная книга по написанию ОС. Vade Mecum. один минус - на английском

!!!! Да вот слона то я и не заметил :)) Круто. Значит есть люди на земле которым все таки не пофиг. Это радует.
Я естественно тоже интересуюсь именно для того чтобы построить ОСь, но заметь, именно построить! Писать ее естественно не мне ни наверное даже 10 таким как я не подсилу и даже не потому что мало нейронов в голове :) а потому что затея дорогая. А вот разработать очень хорошую оську можно. Конечно не все в теории, прийдется конечно и какойто код писать но все же основной упор делаеться именно на структуру ядер, межядер, дров и тд. Ну вот значит будем работать...
... а вот с английским у меня слобовато :( ну ничего, выкрутимся.

2, Xandr=)
может тогда будем вместе разрабатывать?=)))
спонсером всего этого дела пока выступаю я и на свою зарплату...=( но на начальном этапе много и не надо.
Из того же Брукса можно вычитать, что люди разрабатывающие спецификации и структуры необходимы не меньше самих программистов!=) так что если есть желание... милости просим!=)

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

я типа могу присоветовать что нить. только сперва вопрос: что требуется от оси?
про дрова - может стоит их запускать как отдельные потоки в ядре, и прерывания им посылать как сигналы. ввод вывод можно вести через например очередь сообщений типа /dev/a0

про конкрутную ось пока ничего сказать не могу.
сейчас требуется модифицированное экзоядро. а вот уже к нему будет писаться Ось или Оси...
советуй! я всегда готов послушать...=)
_____________________
а почему бы вообще не избавиться от дров? со скриптофилософией это вполне реально. код остаётся одинаковым, просто требуется перекомпилировать...
(я конечно не говорю о таких девайсах, которые часто меняются(хотя мне такие тяжело предстваить)) ведь винт/проц/видяха не так уж и часто меняются. А то уже надоело общатся с дровами...

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

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

как в экзоядре закрыть доступ к всем устройствам вообще? если прога например вирусная.
ну например так - для каждого процесса создается список точек входа в библиотеки. ядро при попытке вызвать точку входа получает #PF - т.к. страница с точками входа помечена как отсутсвующая. после чего выставляет IOPL=3.

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

какраз экзоядро и обеспечивает все 4-ре требования! Да плюс больштнству программистов не придётся сильно переучиваться по части коденья под систему(что обязательно придётся делать в микроядерной), а это огромный плюс.
На данный момент делается вроде так... перед запуском приложения его код сканируется на предмет обращения к ресурсам со всеми вытекающими последствиями.=))(никто не говорит, что и нам так же надо делать). А вообще в экзоядре ОС - это обычное приложение и есно их может быть несколько=))) Может быть даже так, что одна программа может вызывать функции Линукс, WinAPI и ещё иметь прямой досиуп к аппаратуре.=)))
Если интересно, то могу выложить статейку по экзоядру(маленькая - 12 страниц, но на англицком)

Здарова Хлопцы! Это, ну я конечно уже немного пообщался с eXodом, но правда опсуждений было еще аж неодного,
но вот услышал речи Narkomaniusа и сразу вопрос:
Мужики а зачем для програм вам прямой доступ к аппаратуре?
Зачем??? Может всетаки подумать о кроссплатформенности? Ведь эта затея куда перспективнее. К томуже когда все пацаны софтостроения переходят но безопасный софт и виртуальные машины, то я считаю что это нужно учесть. Я конечно люблю Асм и дрюкать девайсы из портов :) тоже, но ведь это все не должно выходить за рамки драйверов! Интересно, как вы думаете: через 5-10 лет пацаны все так же будут чтото строчить в Асме? Да будут, но не то что строчат сейчас. Да уникальные девайсы будут всегда, и не уникальные тоже, и поэтому дрова писать будут тоже всегда,
и естественно что один из лучших языков будет Асм. Но Господа, система должна быть максимум стабильной!!! Скорость тоже не последний параметр. Поэтому я считаю что
Уровень абстракции над железом не только нужен, да он ваще просто НЕОБХОДИМ! А на счет того что дрова запускать в режиме ядра - а зачеи? Что это дает? Может просветите невежду, может ктото и не помнит или не задумываеться но кривой драйвер может запороть Ось в две секунды и со сто процентной эффективностью. Поэтому есть предложение их опускать тоже в разряд обычных приложений, естественно ядро не должно их выкачивать в своп :-) а то прикольно будет - драйвер винта для свопа в свопе :)))). Ну да ладно
есть еще одно:
С че м я согласен на 100 пудов так это с тем что как предложил Narkomanius - <для каждого процесса создается список точек входа в библиотеки> Да это правильно и жизненно необходимо чтобы обеспечить контроль над любым процессом. Идея в том что для каждого приложения подбиваеться список того что ему нужно по замыслу (причем это происходит на этапе дизайнтайма) а если полномочия превышены - милости просим в Аут :).
А как ты Narkomanius смотришь на это?

идеи такие есть и такие ядра называются микроядра. только у них один очень большой недостаток и ещё один(может такой же, а может меньше). Во первых - это самые медленные ядра из всех! Ибо абстракции. А экзо какраз быстрые(именно за счёт возможности прямого доступа к аппаратуре). Проводились исследования(MIT exokernel - можно поискать на яху) и скорость в 10 раз выше чем у нынесуществующих.(кстать, последнии поколения выней какраз являются микроядерными(ну или сильно стремятся к этому)).
А кроссплатформеность решается за счёт использования нового компилятора исповедующего скриптофилософию.=) Да собственно все приложения в экзо и исполняются на ринг3(не помню здесь кто-то вроде говорил... так рингов на самом деле 0,1,2,3 - только используется в основном нулевой и третьий). Воть.

eXod
„а почему бы вообще не избавиться от дров? со скриптофилософией это вполне реально. код остаётся одинаковым, просто требуется перекомпилировать... “

Ещё раз советую обратить внимание на Архитектуру Винды (Драйверы).

Скриптинг устройств - это действительно продвинутая дрянь.
Но. Сами драйвера то всё-равно нужны. А как они будут получены - это никого не интересует.

eXod
Одна из самых мощных моделей абстрагирования (о которой не жалко рассказать :))) - это сервер-ядерная модель.

Она в принципе юзается в Винде и частично в Uinux.

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

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

(Вообще прикол выход... Если создать такую ОСь - то получается что при небольшом переписываении кода - Ось может стоять не на 1 машине а на 2.... и так далее)


Основной плюс серво-ядерной модели - это высокая гибкость.

Опережая ваш вопрос - "а расскажите подробнее".

TCP/IP - это некое подобие того, что можно сделать.

„

Если интересно, то могу выложить статейку по экзоядру(маленькая - 12 страниц, но на англицком)“

Дык - а перевести :) Статья интересная?

„Зачем??? Может всетаки подумать о кроссплатформенности? Ведь эта затея куда перспективнее. “

Не скажи :)
Как бы в будущем не оказалось- что всё железо будет стандартизировано по интерфейсам.

„Поэтому я считаю что
Уровень абстракции над железом не только нужен, да он ваще просто НЕОБХОДИМ! “

НО ЕГО ЛУЧШЕ ДЕЛАТЬ КОМПИЛИРУЕМЫМ, а не ПРОГРАМНЫМ.

И в ЭТОМ ЕСТЬ ЛУЧШАЯ ИДЕЯ ВСЕХ ВРЕМЁН И НАРОДОВ!

Только её никто не понимает :)

„С че м я согласен на 100 пудов так это с тем что как предложил Narkomanius - <для каждого процесса создается список точек входа в библиотеки>“

На самом деле не совсем бы и так.

Это в том случае - если ядро будет отдельным тредом.

А почему бы ядру не выделять специальное адресное пространство - которое будет ему доступно при ОБРАЩЕНИИ этого процесса к ядру (как это сделать - это уже другой вопрос), и которое будет находится в СОСТАВЕ самого процесса (но так, чтобы процесс не имел к нему доступ)

Тогда сами "точки входа" будут ПРИСВАРЕНЫ к программе.

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

Остаётся вопрос - как сделать так.
Есть много хороших путей.

(Смотрите ту же Винду [FS])

Несколько слов о планировщеке.

Зачем с него делать процесс?

Планировщик - находится ЛОГИЧЕСКИ ниже УРОВНЯ понятий "процесс".

То есть то, о чём тут говорится - уже бред по определению.

Тут самое важное - чтобы планировщик работал как можно МЕНЬШЕ (по времени).

Тут можно придумать было бы настраивамые кванты.
То есть чтобы в зависимости от нужды - планировщик либо увеличивал длинну ОДНОГО кванта (на таймере), либо уменьшал.

А алгоритмы распределения времени между процессами - это уже другая сказка :)

Дело в том. что к планировщику ОБЯЗАН быть привязан ещё один механизм - механизм запроса.

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

А ВЕДЬ НИТИ пробуждаются ТОЛЬКО по СОБЫТИЯМ!

Вывод - МЕХАНИЗМ событий ПРОХОДИТ ЧЕРЕЗ ПЛАНИРОВЩИК!
Вот например...

Пусть каждая нить (именно нить а не процесс)

имеет приоритет от 0 до 31.

Пусть таблица расчёта приоритеттов - выглядит в виде
простого линейного списка очереди.

НО!!!! Мы условимся, что приоритет нити НА САМОМ - зависит
ОТ местоположения дескриптора в списке.

ТОГДА = ПРИОРИТЕТ вообще не нужен :)

Пусть в этом списке, который состоит из Указателей на структуру нити и приоритета.

Присутстуют специальные макеры...

Я буду маркировать обычные указатели как ->, а не маркеры *. Вот как выглядит этот список.
каждый элемент


Обратите внимание на избыток информации.
Одна и та же информация хранится несколькими способами.
цель такого пересбытка - повышение скорости работы.


[маркер начала*][чило элементов в уровне][счётчик тиков][->][->][->][маркер конца уровня 1*][чило элементов в уровне][счётчик тиков]
[->][->][->][маркер конца уровня*][чило элементов в уровне][счётчик тиков]
[->][->][->][маркер конца уровня*]

Планировщик - разделяет кванты времени только между задачами ОДНОГО уровня.

Достаётся и другим - однако - это другой вопрос.
(Мы его пропускам)

Для планировщика распеределение времени между маореками одгого уровня - дело простое. Крути себе шарманку в цикле, между элементами уровня.

=======================
ИЛИ ВАРИАНТ 2.
Если в пределах одного уровня нити имеют свой приоритет.
(назовём его - локальным) пусть он равен от 1 до 7
то - планировщик даёт ните столько тиков (в пределах уровня), сколько имеется в локальном приоритете.
=======================

ПРИ ЭТОМ - он постоянно понижает счётчик тиков.
Для чего он?
А вот как раз для того, чтобы давать время процессам более нижнего уровня.
Счётчик тиков - это время голодания для процессов с низким уровнем.

Когда счётчик тиков доходит до нуля - планировшик спускается на уровень вниз, и смотрит - кто там хочет выполнится...
ПРИ ЭТОМ он уменьшает счётчик тиков того уровня!!!
ЕСЛИ счётчик того уровня равен 0
планировщик спускается ещё ниже..
И так далее - пока уровни не будут исчерпаны.
=============================================

=============================================
P.S.
Когда нить меняет свой приоритет - планировщик обязан переместить её внутри списка...


Но на самом деле, он может пометить её (ведь каждый элемент содержит ещё и проритет) - а сам совершить перенос намного позднее - когда будет удобно.

Таким образом задачи планировщика сводятся к минимуму действий.

================================
А вот когда просыпается процесс из более высокого приоритета (а просыпается он всегда ТОЛЬКО по какому НИБУДЬ СОБЫТИЮ)...
Вот тогда планировщик отдаёт время ему.

И всё повторяется :)

=================================
„А кроссплатформеность решается за счёт использования нового компилятора исповедующего скриптофилософию.=) “

Это то, о чём я говорю :) В реалльности - код МОЖЕТ БЫТЬ монолитом - а в программе - пусть будет ЛЕСА этих абстракций.

Кроме того - Я ПРОСТО НАСТОЯТЕЛЬНО РЕКОМЕНДУЮ реализовать серверную модель объектов и ПЛЮНУТЬ на ЭТОТ ООП - он уже давно морально устарел.

2 Edmond, эх как я согласен с тобой по поводу ООП!=)
Млин, сколько ценных мыслей... если не секрет, где берёшь информацию? Похоже всё таки куплю я Таненбаума(и не смотря на то, что стоит он больше 500рэ).=) там по моему написано про клиент-ядерную технологию=)
со статейко про экзо... постараюсь перевести в ближайший день/два и выложу. А по поводу компилятора я немного написал в топике о валькирии.=))