OSDev http://osdev.su/ |
|
Express OS http://osdev.su/viewtopic.php?f=4&t=178 |
Страница 1 из 19 |
Автор: | Himik [ 27 июл 2008, 17:09 ] |
Заголовок сообщения: | Express OS |
Возможно, система станет альтернативой Linux. Соответственно предполагается некоторая совместимость. В данный момент ни какой совместимости с Linux нет, только с WinAPI. Эту WinAPI надо потихоньку менять на POSIX. http://code.google.com/p/express-os |
Автор: | phantom-84 [ 28 июл 2008, 09:23 ] |
Заголовок сообщения: | Re: Express OS |
POSIX не значит Linux, а Linux не всегда значит POSIX. Многое определяют библиотеки. Существуют системы на базе Linux, которые не являются POSIX-совместимыми (конкретные примеры назвать не могу, но не раз встречал упоминания об этом). Нужно определиться, ближе ли тебе принцип максимальной эффективности Linux или принцип максимальной совместимости (переносимости) POSIX. Конечно POSIX-совместимость во многом определяет архитектуру ядра, но мое мнение таково, что Linux нужна была POSIX исключительно ради экспансии в мире nix'ов. Но это в скором может негативно отразиться на Linux. Linux - уже альтернатива. Зачем нужна альтернатива альтернативе, которая пока устраивает практически всех? Нет, это конечно возможно, просто я хочу тебя уберечь от бессмысленной гонки, в которой ты все равно проиграешь. Короче, если хочешь создать альтернативу Linux, на Linux в плане совместимости нужно ориентироваться в самую последнюю очередь. |
Автор: | Himik [ 28 июл 2008, 16:27 ] |
Заголовок сообщения: | Re: Express OS |
Не смотря на то, что в Linux есть библиотеки не относящиеся к POSIX, всё-равно все они базируются на системных функциях POSIX. Тоесть, без POSIX они просто не будут работать. В Express-е POSIX нужен только как низкоуровневая прослойка системных функций, она не будет основной и главной библиотекой. Просто в качестве системного API она вполне подходит. Совместимость с Linux на данном этапе нужна в основном для драйверов, я не буду плодить драйверные модели. Также большинство компиляторов рассчитаны на POSIX, переписывать компиляторы тоже не вижу смысла. |
Автор: | SII [ 28 июл 2008, 20:53 ] |
Заголовок сообщения: | Re: Express OS |
Чем меньше прослоек, тем выше скорость и меньше затраты памяти, поэтому по возможности нужно обходиться без них. В этом плане Винда с её Вин32 АПИ, реализованном с помощью кучи ДЛЛ на базе НТ НативАПИ, сделана откровенно плохо. Поэтому моя кочка зрения по поводу АПИ для оси в общем такова: АПИ, реализуемый "низкоуровневой" частью системы (ядром и драйверами), должен быть достаточен для подавляющего большинства прикладных задач, а значит, должен включать и средства синхронизации и посылки сообщений, и файловый ввод-вывод, и другие подобные функции, причём вызываемые без всяких прослоек и обёрток. А вот сравнительно редко используемые или громоздкие по сути функции (вроде оконной системы) могут быть уже надстройкой-прослойкой: во-первых, они нужны не всем и не всегда, а во-вторых, лишнее время на вызов прослойки будет незначительным по сравнению с общим временем выполнения таких функций. Собственно, такой подход предоставляет, например, ДиректХ: понятно ведь, что прямое обращение к "низкоуровневому" драйверу видюхи в теории обеспечивает более высокую скорость работы, чем то же самое через ДиректХ, однако плюсы (несколько более высокая скорость) незначительны по сравнению с минусами (необходимостью самостоятельно учитывать особенности видюхи и её драйвера, выполнять кучу рутинных вспомогательных операций и т.п.). Что касается компиляторов и АПИ, то, по идее, компилятор от АПИ не зависит вовсе, зависит лишь библиотека времени выполнения в той части, где она соприкасается с системой. Хотя утверждать не буду: возможно, современные компиляторы учитывают какие-то особо тонкие особенности систем (в частности, связанные с SEH -- как сей механизм реализован в Линухе, лично я понятия не имею). Ну а саму идею -- использовать готовые компиляторы, а не изобретать свои -- в целом поддерживаю. Наконец, API Posix в качестве системного АПИ. ИМХО, вполне разумный выбор. Идеалом сей АПИ не является -- сказывается тяжкое прошлое в лице Униха, и некоторые вещи при проектировании с нуля без цели добиться совместимости можно было бы сделать лучше, да только это лишний геморрой, оправданный далеко не всегда :) Ну а на качестве самой оси АПИ вообще практически не сказывается: та же QNX использует как раз API POSIX (точнее, его версию для систем реального времени), однако по надежности оставляет далеко позади всякие линухи и прочие винды. |
Автор: | Himik [ 29 июл 2008, 00:21 ] |
Заголовок сообщения: | Re: Express OS |
Я может быть зря назвал POSIX прослойкой, потому что на самом деле хочу его использовать как основной низкоуровневой интерфейс на ряду со своими собственными функциями, а не как что-то промежуточное между одним и другим. PS. Подскажите пож. насчёт Линукса. Я записал файлы компилятора Open Watcom (http://owbuilder.malakovi.cz) в папку /usr/OW, как сделать, чтобы программы были в общем пути поиска, чтобы запускались из любой текущей директории, по одному лишь имени файла? Наверно нужно сделать линки на программы в системной папке /bin ? Линки делать не очень охота, хочется всю директорию с программами прописать в пути поиска как в DOS. И где в Линуксе прописываются переменные окружения? Использую Debian 4.0 r3. PS2. Нашёл установщик open-watcom-c-linux-1.8 в http://owbuilder.malakovi.cz/snapshot , буду его пробовать. |
Автор: | phantom-84 [ 29 июл 2008, 10:49 ] |
Заголовок сообщения: | Re: Express OS |
Chizh, если набор системных вызовов полон, то на их основе можно реализовать практически любое API, включая POSIX с его незабвенным fork'ом. Просто nix'ам свойственно иметь набор системных вызовов, каждый из которых соответствует отдельной функции базового API. В WinAPI заложен совершенно другой принцип - там такого взаимно-однозначного соответствия между базовым API и системными функциями не наблюдается даже близко. Что лучше - вопрос весьма спорный. Про драйверы вопрос конечно интересный. Я в свое время тоже кое-что делал в этом направлении. Но там скорее важна бинарная совместимость, чем совместимость на уровне API. Кроме того драйверная модель все-таки очень сильно связана с архитектурой ядра. Поэтому ты опять рискуешь встать на путь клонирования Linux. SII, я с тобой согласен во всем, но прослойка, транслирующая обращения к API-функциям в системные вызовы все-таки нужна. Другое дело, что чем ближе набор API-функций к набору системных вызовов, тем проще выполнять такие обращения. Мне, например, нравится идея inline-функций, некоторые из которых подготавливают параметры и напрямую выполняют системные вызовы, а некоторые (те, для которых нет соответствующих системных вызовов) представляют собой обращения к библиотечным функциям. В nix'ах обработка исключений базируется на сигналах. Сигнальный механизм тоже является частью POSIX. Chizh, я не очень продвинутый пользователь Linux, но вроде PATH=$PATH:/usr/OW. Из командной строки: export PATH=... или setenv PATH ... или еще что-то подобное. |
Автор: | Himik [ 29 июл 2008, 16:15 ] |
Заголовок сообщения: | Re: Express OS |
Цитата: Просто nix'ам свойственно иметь набор системных вызовов, каждый из которых соответствует отдельной функции базового API. В WinAPI заложен совершенно другой принцип - там такого взаимно-однозначного соответствия между базовым API и системными функциями не наблюдается даже близко. //Phantom-84 29.07.2008, 10:49 Я не считаю, что все пользовательские функции надо тащить в ядро, потому что вызов ядерных функций дольше, чем функций на пользовательском уровне. Поэтому я за "надстройки". И библиотеками пользовательского уровня проще манипулировать, в смысле добавлять, обновлять, загружать и выгружать из памяти. |
Автор: | SII [ 30 июл 2008, 09:16 ] |
Заголовок сообщения: | Re: Express OS |
Цитата: Я не считаю, что все пользовательские функции надо тащить в ядро, потому что вызов ядерных функций дольше, чем функций на пользовательском уровне Только в том случае, если эти функции не нуждаются в вызове "ядерных" сервисов. Например, какую-нибудь там функцию перемножения матриц точно незачем пихать в ядро. Ну а если это ввод-вывод, то тут ещё нужно хорошенько подумать, что выгоднее, ведь переключаться в ядро придётся в любом случае. |
Автор: | phantom-84 [ 30 июл 2008, 10:33 ] |
Заголовок сообщения: | Re: Express OS |
Даже если нуждаются, API-функцию в определенных ситуациях лучше оставить в прикладном пространстве. Возьмем к примеру FindFirstSomebody/FindNextSomebody. Функцию FindNextSomebody лучше реализовать в прикладном пространстве, если ядро способно за один системный вызов возвратить информацию сразу о нескольких искомых объектах. Зы :) Я сам такое использую только применительно к файловой системе, а к примеру FindFirstProcess/FindNextProcess - это системные вызовы :( |
Автор: | SII [ 30 июл 2008, 10:39 ] |
Заголовок сообщения: | Re: Express OS |
Ну так я и не утверждаю, что в ядро надо пихать всё подряд. Более того, такой подход ни к чему хорошему не приводит. Но принимать решение о размещении той или иной функции в ядре или вне его надо только после хорошего размышления, прикинув при этом, как данная функция будет реализовываться в обоих случаях. |
Страница 1 из 19 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |