OSDev

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

Dragon

Уточняющий вопрос: под "теоретической базой" Вы подразумеваете некий концептуально-технический проект ОС, в котором говорится, какие алгоритмы и решения должны применяться в этой ОС для решения тех или иных задач, но не оговаривается, как именно практически они будут запрограммированы? Например, относительно многозадачности можно принять концепцию "круговое планирование с квантованием времени на основе приоритетов", но при этом нет нужды оговаривать, как конкретно будет осуществляться переключение задач: "ручной" сменой контекста процессора или с помощью аппаратных возможностей, заложенных в архитектуру IA-32.

Даже выше скорее всего. Относительно переключения задач, это могло бы иметь вид:
- Приоритеты
- Разрешение DeadLock'ов
Тоесть грубо говоря, я имею ввиду ориентиры (наброски), к которым ОСь стремится, а только потом технические подробности, что она будет на ia32, и алгоритм переключения будет циклическим. Другими словами, интерфейсы, которые есть (будут) в ОСи для комфортного взаимодействия. Это может быть функциональный API, набор классов или что то ещё(?). Найти бы такой проект, где такое опсание присутствует на каждом элементе (файловая система, драйвера, пользовательский интерфейс, стандартные приложения), тогда думаю, само кодирование заняло бы минимальное количество времени. Так понятнее объяснил?

Dragon



Хм... Тогда получается, что Вы имеете ввиду техническое задание на проектирование. Но ТЗ всегда слишком расплывчаты, и прямо на их основе, без проекта, систему не создать (толку от того, что в задании прописано использование приоритетов -- надо ж решить, как их использовать, какие алгоритмы применять -- а это уже проект, а не задание).



Ну, API весьма и весьма косвенно связан с внутренним устройством системы. Например, стандарт POSIX может быть реализован как системами с монолитным ядром (типа Linux или там Windows), так и микроядерными (пример -- QNX). Т.е. опять-таки это скорей задание, чем проект.

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



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

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



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

Dragon


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



Ну, я тоже спорить не собираюсь :) Могу, правда, заметить, что ни одного аргументированного опровержения данной фразы тоже не существует, потому что на любой аргумент сторонников ООП можно найти не менее веский (в той или иной конкретной ситуации) контраргумент. А абстрактные рассуждения вообще непродуктивы, потому что не учитывают те реалии, на которые "завязан" проект. Сам я являюсь большим поклонником ООП в области пользовательских интерфейсов, начиная со времён Турбо Вижна (то, что временами что-то кем-то реализовано криво, не является виной ООП). Но вот на низком уровне никаких преимуществ сей подход не имеет, да и на высоком они далеко не всегда проявляются.

Ну и, наконец, следует помнить, что ООП -- это инструмент, и превращать его в религиозную догму не стоит (представил себе культ ломопоклонников :))) )

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



Всё зависит от конкретики. Важно соблюдать грань между слишком сильной или слишком слабой детализацией... Грубо - ООП удобно применять начиная со списокв. И удобно применять, если есть нормальные средства компиляции, начиная с базовых типов aka Byte. Только если работать на низком уровне, то становится не просто важным, а очень важным не перегнуть палку ;) // имхо

Dragon


Опять-таки от целей и задач зависит. Например, есть у меня самописные классы для поддержки сбалансированных двоичных деревьев в Дельфи (есно, конкретные экземпляры элементов деревьев создаются из классов-наследников базового класса -- тот определяет лишь функциональность, необходимую для самих деревьев). Использовать вполне можно, но всегда ли разумно? Если у меня 95% времени процессора уходит на собственно задачу, и лишь 5% поглощает поддержка этих самых универсальных деревьев -- то проблема невелика, и удобство использования вполне окупает небольшое падение производительности. Ну а если пропорции обратные, и почти всё время пожирает "универсальное объектно-ориентированное дерево"? Не лучше ли забросить тогда ООП в дальний угол и реализовать узкоспециализированное дерево (а может, и не дерево, а что-то более подходящее в конкретной ситуации)? (Речь, конечно, о том случае, когда время всё-таки важно -- но применительно к ОС производительность является одним из очень важных критериев)

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

В ООП ничего плохого нет. Если использовать полиморфизм и инкапсуляцию, то можно защититься от всякого рода мэджиков. Преимущество - больше, чем даёт класс в своём интерфейсе, сделать с объектом нельзя. Все члены и методы, которые нельзя трогать, надёжно скрыты за private & protected. Если не сильно мудрствовать с деревом наследования, то классы - это те же структуры, а их методы - это те же функции, которым в качестве первого аргумента передаётся this.
Шаблоны - тоже хорошая вещь. Но плодить их без надобности нет смысла. Они резко увеличивают объём кода.
С механизмом генерации и отлова исключений я пока так и не смог разобраться. Но скажу, что на это тратится прилично кода, да и это весьма такая скрытая вещь в себе. Поэтому использовать исключения в ядре крайне не рекомендую.

Так что, разумный подход и знание, того как генерируется код для классов позволят найти оптимальное решение. Пусть и производительность немного упадёт (а, может и вырастет?).