Это вопрос из области философии. L4 X2 предлагает 12 системных вызовов, из которых в User Space активно используются лишь один - L4_IPC.
Разумеется, pthreads никто не отменял. А вот построить ядро на основе многопоточности? Кто может этим похвастаться? :)
С этим не спорю. Разумеется, всё так и есть. До работы с USB, если не случиться чудо, доберусь через полгода-полтора года. Где-то так.
Я не противопоставляю систему Linux. Сейчас это было бы по меньшей мере глупо и смешно. Впрочем, спорить с Вами я тоже не хочу - Вы мне очень помогли, отвечая на вопросы и давая советы. Смысла спорить не вижу. Наоборот, я надеюсь, что Вы мне ещё поможете, как это делали раньше.
Чего же вы тогда на ассемблере не пишите - ведь это же так эффективно :)
посмотрите на список процессов в linux - ps ax.
вот те что в квадратных скобках с PPID 2 ([kthreadd]) - это все потоки ядра - или этого мало ?
В споре рождается истина и эти разговоры всего лишь разговоры, я бы помог вам на фисташку портировать но в okl4 питон 2.4 у меня не заработал нормально и мне неохота систему ломать, а старая фисташка из вашего архива на arm похоже вообще не соберется.
Но непереносимо и геморройно. Говорят, современные компиляторы оптимизируют получше человека. Иногда всё же приходится писать на ассемблере всякие crt0 и тому подобные вещи, но это не от хорошей жизни :)
Упс. Как-то пропустил, надо бы глянуть как оно внутри устроено. Но когда начал писать свою систему, этого не было. Зуб даю, что не было. А прошло всего каких-то 8 лет.
Я расскажу как у меня работает файловая система и почему она не похожа на другие реализации. Писал её в среде MS Visual Studio C++ 6.0. Образы файловых систем сформировал под Linux и перетянул их в Windows. Писал по спецификациям и книжке Таненбаума - всё получилось классно, но в одном потоке. Когда понял, как "форшманулся", было уже поздно - файловая система была готова и вообще не подразумевала многопоточность. Обращение к консоли через файловую систему блокировало все задачи до нажатие пользователем на клавишу. Серьёзная ошибка проектирования, исправление которой потребовал бы полностью переписать код файловой системы...
Но благодаря этой ошибке удалось изобрести хитрый способ - каждому новому запросу из юзерспейса назначать свой стек и переключать стек в зависимости от контекста. Стоимость такой операции ничтожна по сравнению с использованием многопоточности и накладные расходы ~0, блокировок доступа к ресурсам нет даже в принципе. Идентификатор контекста файловая система передаёт дальше вместе с запросами к драйверам устройств, а при асинхронном ответе от любого устройства возвращается идентификатор контекста, на основе которого происходит установка стека соответствующей задачи. Таким образом синхронные сообщения развязались в асинхронные, блокировок нет, накладных расходов на синхронизацию нет и большую часть времени файловая система проводит в ожидании запроса из юзерспейса или ответа от драйверов. Получился класстческий конечный автомат, использующий несколько стэков для хранения состояний каждого запроса.
Поскольку запрос на чтение файла может инициировать несколько обращений к диску (напимер, чтение контрольной информации о файле чтобы найти сектор на диске, затем чтение самого сектора), то между запросом read() и ответом на него, во время операции чтения, другие процессы могут без проблем выводить информацию на экран, ждать ввода с клавиатуры или даже параллельно читать/писать другой файл - и всё это без потери производительности. При этом можно быть уверенным, что не произойдёт рассинхронизации данных, когда несколько задач или юзерспэйс нитей будут обращаться к внутренним данным файловой системы. Даже трудно посчитать, сколько зайцев было убито одним выстрелом.
Собственно говоря, ошибка проектирования сыграла ключевую роль в создании хитрого алгоритма, благодаря которому система выгодно отличается от остальных. К слову говоря, в Solaris на каждую юзерспэйс нить создаётся нить в ядре. Нормально? Я бы так не сказал.
Наконец, предвижу критику апологетов мнопроцессорных систем - мол, глупо и не оптимально в одном потоке разгребать запросы от нескольких процессоров. Якобы потеряются все преимущества от многопроцессорности. А вот и нет! Благодаря переключению контекста на основе стека, все операции файловой системы вырождаются в относительно небольшие участки кода, исполняемые между запросами/ответами. На синхронизацию доступа к общим ресурсам потратится больше времени, чем на обслуживание коротких запросов. Кроме того система станет более отзывчивая, а планировщик задач более простым.
К чему я это рассказываю? Ну, наверное, чтобы ещё через 8 лет повторить кому-нибудь, а мне ответили, что современные системы так и работают. :(
Собирал okl4 на Slackware 12.0.0 python 2.5
Пришлось сделать хардлинк с python 2.5 на python 2.4 и собралось без проблем.
А Вы Линукс в виртуальной машине используете или как основную систему? Я использую Windows и MS Virtual PC со Slackware внутри. Теперь, правда, добавилась VMWare с Debian от starterkit.
У меня нативный ubuntu и с 2.6 такой трюк не проходит
update
хех - переустановил пакеты с python2.4 - вроде задышало :) с тулчейном только проблема возникла - похоже собирать нужно только ихними инструментами..
01.03.2011 18:09
02.03.2011 10:01