OSDev

Однозначно нет. 2048 -- это 11 бит, значит, брать 16, поскольку адресация байтовая.

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

Ты реально не умеешь задавать вопросы. Естественно внутренние описатели объектов, используемые ядром, могут иметь сокращенную размерность. Точнее если они являются индексами или адресами в таблицах, то могут, а если полными адресами, то нет. У меня поля T(hread)S(tructure).proc, TS.pred, TS.next являются полными адресами структур процесса и потоков соответственно, т.е. 32-битными ("исключительно из соображения быстродействия"). Однако в тоже самое время к примеру поле D(evice)S(tructure).master, содержащее ссылку на поток, захвативший устройство, является индексом, т.е. 16-разрядным (исключительно ради уплотнения структуры устройства). Способ представления внутренних описателей, используемых в ядре, может меняться от версии к версии, если ты конечно не задекларировал неизменность такого представления для системных разработчиков и всяких там исследователей ядра (т.е. не сделал глупости). Не вижу никакого ламерства и в использовании селекторов или индексов в процессорных таблицах в качестве внутренних описателей, если это целесообразно. Например, до того, как я перешел на чистое flat-ядро, у меня каждый модуль ядра идентифицировался селектором первого из пары смежных дескрипторов (code & data) в GDT, описывающих адресное пространство модуля.

Ничего не понял. Что за глобальные входы, да ещё пригодные для замораживания, локальные таблицы, через которые открывать можно...

"глобальный вход" = глобальная структура, описывающая объект, или place holder для такой структуры.

"замораживание" = оставление глобальной структуры и самого объекта в (полу)рабочем состоянии только по причине того, что не были вовремя закрыты все локальные описатели этого объекта.

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

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

Это понятно.

Небольшая проблема все-таки есть.Некоторые считают, что применительно к определенным типам объектов (например, к процессам) такое поведение системы не является оптимальным.

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

А почему бы перед выделением идентификатора не проверить его существование? Если с этим индексом объект уже есть, то увеличиваем счётчик ещё один раз и т. д.

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