ОС на FPC

[Sergei I. Gorelkin]

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

[Рождённый_в_СССР]

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

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

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

[bw]

> обычно у ядра просят открыть файл
Ты про микроядро ? Обячно у него таких вещей не просят. Да и вообще оно не выполняет никакх запросов, для этого есть сервера и драйвера (названия могут быть другими, но я оперирую этими).

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

Почитай Таненбаума, посмотри Minix3, может L4Ka. Хотя ты наверняка уже это сделал, раз взялся за микроядро.

..bw

[Рождённый_в_СССР]

ой) Тененбаум )
приятно встретить... да я наверняка это сделал и давно, правда многое уже забыл, потому как тогда не всё понимал...
копировать minix или qnx желания никакого... тут немного другое:

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

1) терминальный вывод 2) менеджмент памяти 3) работа с диском

кеширование опять же на уровне ядра и только (!) или теряется ВООБЩЕ смысл Intelовской модели страничной адресации

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

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

опять же вникший читатель скажет что это уже не имеет права называться микроядром - отвечу ИМЕЕТ ! - потому что любой желающий может вспомнить мою идею пересборки, залесть (пока ручками) и отключить в файле /services/list.inc все сервисы которые считает не нужными микроядру, компилирует и вуаля получает микроядро - а далее пишет себе эти драйверы и сервисы хоть в чисто абстрактном уровне,
мне же нужно чтобы эти сервисы были именно в ядре

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

[@lex]

Интересная штука с точным названием - Стимул для разработчиков на Pascal
Главное - не сдаваться, ведь Линус тоже все делал "Для прикола" и чем в итоге это обернулось... Жаль только что он все делал на С

[bw]

Я пока не понял как его собрать. Рождённый_в_СССР, дополни исходниками документацией по сборке и др. комментариями.
А еще мне не понравилось форматирование кода , все же это очень важно писать не как тебе нравится, а как это принято (а вообще есть ли какие то рекомендации по форматированию кода?). Хотя на код самого FP я тоже без слез смотреть не могу, мне нравится как код оформлен в VCL.

..bw

[Рождённый_в_СССР]

сейчас уже дописывается то, что хотелось увидеть от след. версии (работа с файловой системой)... меня запутала теория реляционной модели данных... я всё пытался уйти от стандартной для ФС сетевой (FAT) и иерархической (extfs) к реляционным (на которых почти все современные БД работают), но что-то застряло у меня на всяких нормализациях... поэтому вернулся к старому варианту пока... но в будущем я обязатльно вернусь к этому вопросу, как только появится что-то вроде менеджера памяти для процессов управления... если кто знает чего-нить о использовании реляционной модели (вернее какой её модификации) в ФС, плиз сообщите

to bw
по поводу форматирования - я его обязательно проведу, обещаю... просто здесь вопрос стоит глубже... не только в оформлении кода... а вообще... смотрим POSIX... и завидуем... так это должно выглядеть... пока придерживаюсь только правил, необходимых для оптимального кода... а с самим видом конечного кода я пока не решал... скажем вас устроит венгерская нотация? конечно с некоторыми изменениями... это стандарт на переменные (создан при написании первой winapi) а само оформление кода - я стандарты не видел, только рекомендации всякие в старых книжках для TP.. но кто мешает всё это собрать в один список и назвать стандартом, аналогично POSIX в Си... тем более он определённо понадобиться при написании терминала и организации системных вызовов... а сам posix как я понимаю в паскале не уместен ) нужна банальная замена небольшой части с учётом синтаксиса паскаля, если мы хотим получить что-то серьёзное... начать наверное следует именно с оформления кода! )

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

упрощена компиляция до двух сборочных файлов - Buid_All - собирает микроядро и всё чего с ним завязанно, build.bat - создает файлувую систему, объеденяет с ядром и выдает готовый бинарник.

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

[bw]

По сборке:
Ну build_all нету, максимум похожее на него это BUILD_~1.EXE . Потом 5 исполнительных файлов в каталоге с исходником сбивают с толку, даже если их автору их имена кажутся говорящими. (Все файлы, что не должны запускаться пользователем непосредственно я именую начиная со знака подчеркивания.) Код, который занимается сборкой, нужно по максимум вытащить в скрипты оболочки. Так же нужно позволить пользователю через установку переменных окружения (set FPROOT=C:\FP211) определить все что невозможно сделать автоматом.

По коду:
> мне нравится как код оформлен в VCL.

..bw

[Alexander]

А вот и ещё одна ОСька ! Люблю я это дело.

Дополню парой соображений.

ДОС и пр. совместимость - нафиг. Никогда ещё не удавалось
сделать нормальную совместимость чего либо с чем либо.
ДОС делался совместимым с СиПиэМ и что, кто нибудь запускал
сипиэмовские проги под ДОС ? А совместимость болталась и
загромождала. И много других примеров. Не вспомню все.
Да и на другие архитектуры ДОС не портируешь.
А вот о поддержке виртуальных машин, наверное, надо подумать.

Кстати а как у ОСи с многоплатформенностью ? Я понял, что никак.
У ОСи не будет развития если не будет поддержки разных архитектур.
MIPS, ARM ...

В качестве системного языка лучше было бы использовать Оберон тк
он создавался сразу как системный. И вообще он более далеко
продвинулся.

Разработку стоит вести Линуксе. Несравнимо удобнее. Устройства
представлены как файлы. Есть богатейший набор утилит для
разработки. Те исключаются такие недоразумения, как abscopy.com и
build_all.pas.

Самая свободная из всех лицензий - BSD

Между свободой и рабством один шаг. Линукс обогнал xBSD за
счёт GPL. Разработчики больше доверяют той лицензии, котрая
больше защищает от "приватизирования" третьими лицами.

Не понял микро-. Сейчас она мне кажется вообще с монолитным
ядром. Где же загружаемые/выгружаемые модули ?

И вообще - сейчас, похоже, идёт разработка "снизу", без взгляда "сверху" и "издали".

Но зато поборот защищённый режим - это плюс.

[w-tools]

Приветствую Всех!!!

Рождённый_в_СССР, просмотри эту тему полностью вот по этой, ссылке:
http://meos.sysbin.com/viewtopic.php?p=11011

Как то всвое время уменя выкристализовалась в голове вот такая структура OS, почитай, с нетерпением жду твоих коментариев

[Рождённый_в_СССР]

almаn
Идут, но плохо... вы не поврите до сих пор (!!!) (одного восклицательного знака мало показалось ) мучаюсь с реляционной файловой системой - никак не могу постороить её с толком - только придумаю организацию - вроде даже неплохую - начну на практике реализовывать - выясняется что некоторые важные вещи не учтены - начинаю их учитывать - теряется скорость работы, связанная с постоянной переогранизацией (кривой нормализацией) данных... я защищённый режим помойму меньше постигал, чем эти таблицы... стыдно конечно, но времени мало выделяется - я в основном занят своей дипломной и на работе грузят - всего два программера осталось - заставили 4 системы одновременно разрабатывать и буквально до нового года... Правда жизни победила - придётся делать сместь кластерной и иерархической ФС, как задумывалось раньше. Советы с работой какого либо FAT или EXT(N) отвергаю сразу (а их было много)... на это есть несколько причин... в любом случае это всё будет реализовываться на уровне внешних сервисов, но уже потом, сейчас главное заставить ядро достойно общаться с диском.

Примеры, где под микроядром что-то работает реально быстрее я, впринципе, встречал... но как то всё неубедительно если смотреть философски - реально выполняется больше действий при вызове одних и тех же функций - это мне напоминает резню между компиляторами и интерпритаторами, так последние (JIT/.NET) вечно доказывают что чего то там могут делать быстрее компилируемого кода... да не в скорости дело - а в переносимости, плюют все интерпритаторы на скорость, ПЛЮЮТ !!!
и тут помойму тоже - вечно микроядерщики чего то хотят в скорости обогнать... я думаю это не верный ход - их основная фишка это безопасность и стабильность, но никак не скорость.

w-tools
гениальный ход) нет, я серьёзно... имхо нужно внести больше абстракции на уровне описания в ТЗ. Я думаю получится уникальный документ тогда - так сказать всем, с чего начать и что делать вообще, чтобы ОС не выкинуть, а гордится ей.
Единственное, возникает куча вопросов к пункту

3.2 Дополнительные требования к микроядру

нет, не у меня ) а у народа... мне то по большому счёту все равно где и как оно написанно, лишь бы работало, т.е. выполяло свои функции... моя задача их туда заложить - а не охватовать одной верёвкой весь лес... а вот народ меня постоянно на форуме тут и на почту мучает всякими AMR... всех так этот вопрос беспокоит, как жизнь на марсе буквально... имхо как мне делать будет нечего я перепешу аппаратно зависимую часть (а это ВСЁ, что на асме написанно под ARM), а пока у меня таких задач нет, сама архитекутра физически у меня тока разве что на телефоне есть, но там прошит изначально win mobile и ничего другого туда записать как ОС нельзя, так что испытывать тоже негде... но напомню ВОЗМОЖНОСТЬ есть... не нада топтать и ругаться что этого нет, вот каждый обязательно спросит про эти архитектуры...

кстати у меня появился источник вдохновения -
http://rusosdevelop.narod.ru/
http://www.psix-os.narod.ru/
горжусь этой оськой ) пример как правильно писать ОС - это несомненно РусОС...
это я к вопросу всяких пустых обсуждений

[Alexander]

это я к вопросу всяких пустых обсуждений

Я не пустое говорю и не первый раз.

1 Зачем использовать менее совершенный язык, если можно самый.

2 Совместимость действительно не нужна. Пустая трата сил и байтов.

3 Не надо делать новых Менуэтов. Прежде чем что либо кодировать
нужно хорошо подумать, что хочешь иметь в результате.

4 Лицензия БСД это не лицензия, а дырка.

[Alexander]

Рождённый_в_СССР

Ты Линукс освоил ?

[ev]

ли может лучше сделать форк какого-то существующего ядра, например Linux...

итак от них уже глаза рябит

[Alexander]

итак от них уже глаза рябит

Это на случай, если очень хочется