Эксперимент

[lvd]

В Unix-системах драйвера взаимодействуют с программой пользователя как файлы устройств. В этом отношении мне Юниксы нравятся своей простотой и логичностью. Возможно мы имеем ввиду разные файловые системы ? Есть файловые системы хранения файлов на физ. уровне (FAT, Ext2 и тд), а я говорил о виртуальной файловой системе, которая объединяет все файловые системы в одно дерево. В этом дереве - и фйлы данных и файлы устройств и файлы-ссылки и т.д. и т.п.

Это как раз идеология унихов - всякие там / и все девайсы как файлы etc. В результате имеем монструозное ядро. Да и к тому же унихам ММУ нужен (ну есть конечно uClinux, но думаешь он спасёт на Z80?).

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

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

[Advertiser]

[SfS]

Это как раз идеология унихов - всякие там / и все девайсы как файлы etc. В результате имеем монструозное ядро. Да и к тому же унихам ММУ нужен (ну есть конечно uClinux, но думаешь он спасёт на Z80?).

ММУ - не обязателен, хотя и желателен. Что касается "монстроидности" ядра - все зависит от набора его функций. Если взять минимальный набор - то ядро совсем компактненькое получается. Реально - у меня для ARMа реализация менеджера памяти (кстати - тоже без ММУ) и стандартного интерфейса драйверов - около 5 Кбайт занимает. И это учитывая, что длина команды ARMa - 16 бит всегда (в режиме THUMB, который я использую). Для Z80 - программа явно короче будет.

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

Основная память и ресурсы - жруться не ядром ОС, а программами пользователя и подгружаемыми драйверами. Отсюда вывод - чем больше у тебя устройств приткнуто к спеку - тем больше памяти драйвера будут занимать. Сколько временннЫх ресурсов ОС жрать будет - это вообще отдельный вопрос. Тут все зависит от того какой тип многозадачности и какими приоритетами обладают задачи. Главное - следует помнить, что большинство функций ОС запускаются не "сами по себе", а только в результате обращения к ОС программы пользователя.
Особенно важно распределить приоритеты задач. Я в свое время писал для AT90S8535 программку для управления тех процессом. У меня была жесткая привязка к реальному времени следующих вещей - 4 7сегментника, три канала АЦП - измерения напряжения трежфазной сети. Молодой был, глупый. Пока приоритеты правильно между задачами не распределил - индикатор маргал неравномерно и ьбезбожно, сеть мерялась ужасно. Думал быстродействия не хватает, а оказалось - приоитеты задач - это не пустой звук. Переделал - все как часы заработало.
С точки зрения программ пользователя - ресурсопрожорливость вообще не оценить - откуда я могу знать какой очередной изврат "крутых хацкеров" пожелают под ОС запустить ? Скорее всего придется делать режим "монопольное использование процессора" для нормального запуска программ, где все привязано к тактам проца.

[Vitamin]

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

1) многозадачность нужна. как показывает практика, большую часть времени процессы проводят в ожидании ввода/вывода, т.е. ожидания чтения с носителей (в случае спека не совсем актуально- чтением занимается процессор) или ввода пользователем чего-нибудь. имеет смысл использовать свободное время с пользой.
2) прошивка ядра ОС вместо ПЗУ (как вариант- кеш), потому что основной памяти и так мало
3) делать ядро из модулей (типа линуха). в начальной поставке идет универсальное ядро, поддерживающее всевозможное железо или минимальную конфигурацию, работающую где угодно. юзер на целевой машине конфигурирует сборщик, определяя нужные ему возможности и выкидывая ненужные. ядро пересобирается. все довольны.
4) графический пользовательский интерфейс (не путать с Hacker User Interface ) возможен, но далеко не обязателен, а в силу ограниченных возможностей и нежелателен. отсюда вытекает невозможность привязки событий и проч. к оконной структуры (как в винде). имхо, следует обратить свой взор к *nix системам (что было сделано в предыдущих постах)
5) если углубляться дальше, то нужно затронуть тему диспетчеризации процессов. с целью уточнения, проконсультировался с преподом у себя в универе. согласно выдвинутым требованиям, он предложил схему с двумя классами процессов- реального времени и разделения времени. процессы реального времени выполняются каждый квант диспетчеризации по цепочке. это могут быть процессы времени, обслуживания ау и проч. остальные процессы распределяются согласно своим приоритетам в оставшееся свободное время.
6) менеджмент памяти. вот тут возникают довольно большие проблемы. в частности изза страничной организации памяти. нижнюю память можно отдать на откуп системы для хранения структур, таблиц и проч. а в верхних страницах хранить процессы. проблема в диспетчере, который должен обеспечивать контроль всей доступной верхней памяти (пусть с точностью до блока в 256 байт)- сложности в ее переменном количестве и возможности разделения одной области памяти несколькими процессами. в принципе эта проблема почти решена, дело за реализацией чтобы проверить идею.

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

[SfS]

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

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

2) прошивка ядра ОС вместо ПЗУ (как вариант- кеш), потому что основной памяти и так мало

Однозначно - кэш. Тогда ОС можно апгрейдить и изменять без перепрошивки ПЗУ. Огромный плюс.

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

Ядро и драйвера к нему должно поставляться либо в исходных текстах (для крутых кульхацкеров) либо просто под конкретную конфигурацию, которая в общем определяется набором встроенных- и подгружаемых драйверов. Скажем будет версия "SuperpuperOS v,Pentagon-1024" или версия "SuperpuperOS v,АТМ-7.10". Пользователь ее скачивает, устанавливает и работает - без гребли с компиляцией.

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

Привязка событий к окошкам - это извратик. Есть понятие "процесс". Есть понятие "сигнал". Несколько "процессов" могут обмениваться "сигналами" межу собой. А рисует процесс окошко или передает данные по модему - не принципиально.

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

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

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

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

Распределение памяти мне видется примерно таким:
------------------------- #FFFF
Пользовательские процессы.
------------------------- #C000
Область разделяемых данных
------------------------- #8000
Системные таблицы+подгружаемые драйвера
------------------------- #4000
Ядро+встроенные драйвера.
------------------------- #0000

Такая схема будет работать минимум на 128к, если есть возможность повешать на NMI таймер (хотя можно и через INT - но повиснуть может). Главное, чтобы имелся порт для включения теневого ОЗУ с адреса #0000.

[random]

в общем я полностью согласен, именно так себе и представляю такую ОСь.

только одно дополнение к таблице памяти - возможное резервирование экрана (пускай даже Ч/Б) максимум 6912 байт.

[CityAceE]

Теоретиков, вижу, много. А где же практики???

[random]

давайте уже составлять ТЗ, я повторяю, готов потратить часть своего свободного времени на написание C кода.

[Vitamin]

Теоретиков, вижу, много. А где же практики???

теория обязательно должна предшествовать практике. иначе будет бесполезная трата сил и времени на заведомо неправильные вещи %)

[acidrain]

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

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

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

[Vitamin]

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

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

Однозначно - кэш. Тогда ОС можно апгрейдить и изменять без перепрошивки ПЗУ. Огромный плюс.

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

Ядро и драйвера к нему должно поставляться либо в исходных текстах (для крутых кульхацкеров) либо просто под конкретную конфигурацию, которая в общем определяется набором встроенных- и подгружаемых драйверов. Скажем будет версия "SuperpuperOS v,Pentagon-1024" или версия "SuperpuperOS v,АТМ-7.10". Пользователь ее скачивает, устанавливает и работает - без гребли с компиляцией.

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

Привязка событий к окошкам - это извратик. Есть понятие "процесс". Есть понятие "сигнал". Несколько "процессов" могут обмениваться "сигналами" межу собой. А рисует процесс окошко или передает данные по модему - не принципиально.

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

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

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

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

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

Распределение памяти мне видется примерно таким:
------------------------- #FFFF
Пользовательские процессы.
------------------------- #C000
Область разделяемых данных
------------------------- #8000
Системные таблицы+подгружаемые драйвера
------------------------- #4000
Ядро+встроенные драйвера.
------------------------- #0000

Такая схема будет работать минимум на 128к, если есть возможность повешать на NMI таймер (хотя можно и через INT - но повиснуть может). Главное, чтобы имелся порт для включения теневого ОЗУ с адреса #0000.

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