OSDev

Подскажите, где почитать про проектирование API операционных систем? Очень хочется сделать максимально простой и логичный интерфейс программирования. Не могу определиться с концепцией...

Ну, у меня источники только старые, в Сети не встречал. А новые книги -- не знаю, что там написано по этому поводу.

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

Например, в моей любимой RSX-11 есть один недостаток: там присутствует несколько вызовов для запуска задач ("процессо-потоков" -- многопоточных приложений в смысле Windows в ней не было). Эти вызовы, хотя делают в целом общее дело (планируют на выполнение задачу), различаются в частностях. Например, есть вызов для запуска в определённое время, а есть вызов для запуска "вообще" (всего их вроде 4, лень смотреть). На мой взгляд, это неудобно: лучше был бы один вызов, где всё необходимое указывается параметрами. В конце концов, многие действия у таких вызовов общие (что и подтверждает изучение исходников RSX-11: там вызываются одни и те же подпрограммы, которые выполняют основную массу работы).

С другой стороны, весь ввод-вывод осуществляется в RSX-11 одним по сути вызовом -- QIO$ (и его разновидностью QIOW$, что тоже излишество -- хватило бы только второго вызова). Конкретная операция ввода-вывода задаётся двумя первыми параметрами, причём собственно ось лишь проверяет корректность этих и других параметров по некоторым шаблонам и "разруливает" запросы по драйверам устройств, которые, собсно, и выполняют ввод-вывод. Можно, конечно, выделить отдельные запросы OPEN, CLOSE, READ, WRITE, IOCTL -- но и только. Дробить на более мелкие смысла лично я не вижу (нет, например. смысла различать открытие файла на чтение и на запись и выделять отдельно создание файла -- а такое встречается временами).

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

Интересно...
А имеет смысл делать объектно ориентированный API? и если да - то какие идеи есть по этому поводу?
Интересно, какие основные операции можно выделить для работы над объектами, чтобы получился небольшой и разумный набор?

Абсолютно не имеет, ИМХО. И вообще, "объектной ориентированности" в оси не место. Нет там ничего, где ООП можно было бы применить с выгодой. Речь, есно, о "полноценном" ООП, а не с некоторыми элементами, которые применяли задолго до "официального" появления ООП и даже не подозревали, как это называется :)))

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

Посмотри POSIX, посмотри WinAPI, сопоставь и придумай что-нибудь своё. Я всё же остановился на реализации модифицированного POSIX.

Тогда такой вопрос: какие элементы ООП следует использовать, какие - нет? (если использовать не в чистом виде, а по частям)

Естественно предполагается, что все программы будут ориентироваться на этот самый API, и если он будет объектным, то и все программы будут иметь представление об ООП, единое для всей ОС. Как следствие, и языки тоже.

Где можно почитать про POSIX, в наиболее лёгком виде? Чтобы только поверхностно ознакомиться с идеями... с винапи я работаю, а про POSIX толковых документов не встречал... Кстати, это вроде процедурно ориентированный стандарт?

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


почитай The GNU C Library.

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

Можно попытаться, конечно, притянуть "за уши" ООП к API. Например, для большинства, если не всех, объектов, с которыми задаче приходится работать, существуют функции получения и прекращения доступа -- назовём их Open и Close. На входе Open получает некое высокоуровневое имя объекта (например, спецификацию файла, имя процесса или там какого-нибудь мьютекса), на выходе возвращают некий дескриптор, обеспечивающий в последующем быстрый доступ к этому объекту. Поэтому можно реализовать внутри системы (и на уровне API) эти функции как виртуальные в классах, порождённых от общего базового класса "обобщённого объекта". Однако сразу можно обратить внимание на две вещи: во-первых, получение доступа (открытие) файла, процесса и мьютекса -- по существу абсолютно разные вещи в реализации; во-вторых (и это является следствием из первого), общего кода в реализации этих действий практически нет, разве что учёт количества ссылок и обеспечение безопасности. К этому можно добавить и "в-третьих": другие функции, отличные от открытия-закрытия, имеют ещё меньше общих моментов, их даже нельзя снабдить одинаковым списком параметров без потери эффективности (ведь список придётся предусматривать "по максимуму", для самого требовательного вида объектов), ну а без общего списка параметров нельзя задействовать полиморфизм -- самую мощную, пожалуй, черту ООП.

Я на си не пишу, поэтому у меня нет гемора с шаблонами ;) Всё решается на уровне архитектуры (и указателей, хехе :)).



Если продолжить аналогию, ещё работа с иерархией (NextObject, AddObject, DelObject) и потоками (ReadData, WriteData). Исхожу из того, что к примеру, в WinAPI, есть две группы функций (файловые и реестровые), абсолютно идентичных по смыслу. Как раз получаем, что реализация может отличаться, а интерфейс можно использовать один и тот же. Да, между мьютексом и файлом общего мало... Зато например между папкой и окном можно выделить общие черты - содержание вложенных объектов (файлы и контролы соответственно).

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