Эксперимент

[SfS]

народ восставал против NMI по той причине что не надо вмешиваться в аппаратуру. имхо модульная структура позволит использовать все что угодно.

NMI - это идеальный вариант. МОжно и стандартный INT - это не принципиально. Так что если "народ восставал" - то пусть юзают стандартный INT. Но тогда зависшую после DI программу - не снимешь без рестарта. Впрочем - можно написать поддержку и NMI и INTа - пусть кому что нравится юзают.

а с другой стороны практически полное отсутствие защиты от несанкционированной записи в ядро

Ну это уж не проблема. Кому очень захочится такой защиты - могут сделать порт блокировки записи в нижние 16к ОЗУ. Или лучше - порт, который позволяет блокировать запись в любую из 4х страниц. Большинству же это поровну. ИМХО, для большинства - прошить ПЗУ большая проблема, нежели мириться с отсутствием защиты.

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

Ну это кому как удобнее. Совершенно непринципиальный вопрос.

ну должен поддерживаться стандартный джентльменский набор IPC: семафоры, критические секции, сигналы, каналы

В иделае - да. Но надо начинать с минимума. ИМХО, минимум - это разделяемая память, стандартный интерфейс драйверов и менеджер задач. Если пытаться реализовать все сразу - то только мороки больше будет.

выделять по 16 кило на процесс- слишком жирно. плюс желательно предусмотреть возможность использования одного куска кода разными процессами (тогда можно будет делать fork и не ломать голову с нитями)

Сразу в стандарте POSIX мыслишь ? ))) МОжет форки и нити на чуть потом оставим ?)
Я и не собирался 16К на процесс выделять. В ядре хранится таблица свободных странц и для каждой страницы есть флаг - занята она целиком под процесс или частично. Если целиком - то все понятно. А если частично - то на странице присутствует структура, типа локальной кучи. Таким образом на странице может быть много процессов.

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

Тут подходов может быть несколько. Не на всех компах все сработают. Скажем там где можно щелкать не только последние 16К памяти - все упрощается. На 128й стандартной машине - вообще сложно сделать нормально по быстродействию. Моя точка зрения - надо делать все по минимуму. Тогда быстрее будет виден результат. А затем уже дополнять чего не хватает.

Короче так или иначе - надо ориентироваться на 128к - стандарт как минимум. Для навороченных машин типа ATM - другой менеджер памяти однозначно нужен.

[acidrain]

LVD писал:
По крайней мере так ось сделана на амиге - всем осописателям кстати рекомендуется ознакомиться. =)

Тем более, что аос - это легкая (как в плане освоения, так и в плане кодинга) и удобная операционка 8).

Простота работы с либлами и ресурсами там на высоте. Присоеденяюсь к совету LVD - не зацикливайтесь вы на унихах и пц, есть и другие оси

[acidrain]

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

Я не согласен. Не нужно мне клона линукса, где надо все компилить и пр. мне не нужно делать чужую работу - мне охота купить, вкл. и работать (с минимальными настройками). Все должно быть в комплекте, если челу не нужно что-то, то просто "это" удалит.

4) графический пользовательский интерфейс (не путать с Hacker User Interface ) возможен, но далеко не обязателен, а в силу ограниченных возможностей и нежелателен. ...

Обязателен в минимальной конфигурации. Мне не нужна коммандная строка, вместо нормальной работы с процессами. Если будет нужна консоль - вызову ее. =)

Всего лишь сугубо личное мнение, на которое можно не обращать никакого внимания, но другая ось на спеке мне не нужна =)

[SfS]

Я не согласен. Не нужно мне клона линукса, где надо все компилить и пр. мне не нужно делать чужую работу - мне охота купить, вкл. и работать (с минимальными настройками). Все должно быть в комплекте, если челу не нужно что-то, то просто "это" удалит.

И то и то нужно.

Обязателен в минимальной конфигурации. Мне не нужна коммандная строка, вместо нормальной работы с процессами. Если будет нужна консоль - вызову ее. =)

А какое отношение работа с процессами имеет к пользовательскому интерфейсу ? ИМХО - никакого. В ядре точно графическому интерфейсу делаить нечего. Только вкомпиленные драйвера стандартного экрана допустимы. Хочешь всегда работать в графике - поставил установку, чтобы GUI сам грузился - и все.

Всего лишь сугубо личное мнение, на которое можно не обращать никакого внимания, но другая ось на спеке мне не нужна =)

Радуйся, если хоть какаянибудь для начала появится )) Явно что ось для спека - не будет похожа ни на что другое)

[Vitamin]

NMI - это идеальный вариант. МОжно и стандартный INT - это не принципиально. Так что если "народ восставал" - то пусть юзают стандартный INT. Но тогда зависшую после DI программу - не снимешь без рестарта. Впрочем - можно написать поддержку и NMI и INTа - пусть кому что нравится юзают.

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

Ну это уж не проблема. Кому очень захочится такой защиты - могут сделать порт блокировки записи в нижние 16к ОЗУ. Или лучше - порт, который позволяет блокировать запись в любую из 4х страниц. Большинству же это поровну. ИМХО, для большинства - прошить ПЗУ большая проблема, нежели мириться с отсутствием защиты.

собсно да, но просто надо с осторожностью относиться к аппаратным доработкам

В иделае - да. Но надо начинать с минимума. ИМХО, минимум - это разделяемая память, стандартный интерфейс драйверов и менеджер задач. Если пытаться реализовать все сразу - то только мороки больше будет.

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

Сразу в стандарте POSIX мыслишь ? ))) МОжет форки и нити на чуть потом оставим ?)
Я и не собирался 16К на процесс выделять. В ядре хранится таблица свободных странц и для каждой страницы есть флаг - занята она целиком под процесс или частично. Если целиком - то все понятно. А если частично - то на странице присутствует структура, типа локальной кучи. Таким образом на странице может быть много процессов.

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

Тут подходов может быть несколько. Не на всех компах все сработают. Скажем там где можно щелкать не только последние 16К памяти - все упрощается. На 128й стандартной машине - вообще сложно сделать нормально по быстродействию. Моя точка зрения - надо делать все по минимуму. Тогда быстрее будет виден результат. А затем уже дополнять чего не хватает.

Короче так или иначе - надо ориентироваться на 128к - стандарт как минимум. Для навороченных машин типа ATM - другой менеджер памяти однозначно нужен.

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

[Vitamin]

Тем более, что аос - это lite unix 8).

Простота работы с либлами и ресурсами там на высоте. Присоеденяюсь к совету LVD - не зацикливайтесь вы на унихах и пц, есть и другие оси

человек советует юних и советует на нем не зацикливаться
а где можно взять инфу по этой ОС? а то заинтересовало

[Vitamin]

Я не согласен. Не нужно мне клона линукса, где надо все компилить и пр. мне не нужно делать чужую работу - мне охота купить, вкл. и работать (с минимальными настройками). Все должно быть в комплекте, если челу не нужно что-то, то просто "это" удалит.

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

Обязателен в минимальной конфигурации. Мне не нужна коммандная строка, вместо нормальной работы с процессами. Если будет нужна консоль - вызову ее. =)

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

Всего лишь сугубо личное мнение, на которое можно не обращать никакого внимания, но другая ось на спеке мне не нужна =)

в споре рождается истина (с) ктото древний

[elf/2]

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

а не стоит ли начать с глобального вопроса/опроса: зачем вам нужна ОС на спекке, какие задачи вы хотите возложить на ОС?

имхо, от ответа на него будет зависеть очень многое. например: имеет ли смысл задумываться над многозадачностью/GUI/консолью...

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

[acidrain]

человек советует юних и советует на нем не зацикливаться
а где можно взять инфу по этой ОС? а то заинтересовало

я несколько дезинформировал тебя и всех присутствующих, приношу свои извинения. аос - самостоятельная ось, не похожая ни на что другое. Хотя (судя по истории амиги) изначально вся аос планировалась наподобие никсов, тк один из кодеров до этого работал (точно не помню кто и что делал) над униксами.
А инфа какого плана тебя интересует? конкретно описания функционирования аос? могу выслать, как уже предлагал lvd, описание библиотек и на словах объяснить как оно работает=)

Есть еще огроменная фало по этому поводу, тож можно найти...

[acidrain]

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

Толком не пробовал, вызвала внутреннее отвращение, как и виндовз. Выжигать не из пзу, ведь уважаемая тобой линух не записана в пзу? Повторять ошибки синклера? Нет уж увольте... =)

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

Ду маешь я об оси сужу по стрелочкам и окошкам?