Сегодня, ровно через месяц после того, как это сделали наши старшие братья, команда разработчиков KolibriOS выложила на SVN юбилейную правку (№4000). Автором этого коммита совершенно случайно стал основатель проекта Mario_Z.
Скачать самую свежую ночную сборку можно здесь: kolibrios.org/ru/downloadЧитать полностью »
Несколько дней назад, на форуме KolibriOS зарегистрировался англоязычный пользователь с ником mdickie, и пожаловался, что в его ноутбуке Dell Latitude C640 не работает мышь: board.kolibrios.org/viewtopic.php?f=4&t=2389. Так как недавно у нас появилась поддержка USB (в частности, USB-мышей), то наш основатель Mario_Z логично предположил, что mdickie использует какую-то старую версию, и посоветовал ему скачать последнюю ночную сборку и проверить на ней.
Предположение Mario_Z оказалось верным — в ночной сборке мышь заработала, но сломалось что-то другое:
It works with the latest build,
Thanks
EDIT: It freezes slower.
К сожалению, пользователь был немногословен (либо английский — не его родной язык), поэтому некоторое время мы выясняли, что же именно не так, задавая наводящие вопросы, пока картина не прояснилась:
I mean it needs a little more time to freeze the mouse.
Oh yes, the whole system freezes. The Keyboard and the clock aren't working.
Здесь уже я догадался, что причиной зависания, скорее всего, является драйвер SATA IDE, который в настоящий момент разрабатывает Mario_Z. На данный момент, в KolibriOS есть родной драйвер только для контроллера PATA, а поддержка контроллера SATA в режиме IDE осуществляется только через BIOS, что вносит 2 ограничения:
Ввиду этого, на сегодняшний момент у нас пишутся 2 драйвера SATA (параллельно):
Оба драйвера имеют одну неприятную особенность — наглухо подвешивать систему в случае любой нештатной ситуации — и тогда требуются логи, чтобы увидеть конфигурацию дисков и попытаться узнать причину зависания. Именно это и произошло у mdickie, и поэтому я попросил его приложить логи. Естественно, при зависании всей системы скопировать логи прямо из KolibriOS в текстовый файл не получится, и в таких случаях мы просим сфотографировать лог с экрана монитора на смартфон или фотоаппарат, и выложить фото на нашем форуме. И здесь мы переходим ко второй части статьи.Читать полностью »
Так уж получилось, что, кроме меня и CleverMouse, ни у кого из членов проекта KolibriOS, присутствующих на Хабре, нет свободного времени (желания, умения — нужное подчеркнуть) писать статьи в наш блог. Мы двое, параллельно работая на основной работе, не можем уделять блогу достаточно времени, чтобы статьи появлялись регулярно хотя бы раз в неделю (напомню, что занятие KolibriOS — для нас всего лишь хобби, и вся работа над этой операционной системой ведётся на добровольных началах).
Как вы могли заметить, новых статей в блоге не было уже больше месяца, потому что последний месяц мы оба заняты на работе больше обычного. Я даже всё не могу дописать обещанные 2 статьи про Кикстартер. И мне очень жаль, что такая хорошая вещь пропадает блог простаивает.
Поэтому я решил попытать счастья на бирже авторов (это разрешено на Хабре). Любой пользователь, желающий писать статьи в блог KolibriOS, может связаться со мной посредством личного сообщения на Хабре, либо на нашем форуме, или просто написать комментарий в этом топике и предложить свою кандидатуру, и тогда я свяжусь с ним сам. Писать можно будет о чём угодно — главное, чтобы это было как-то связано с KolibriOS. Примеры идей для статей:
и т.д. Темы для статей — исключительно на выбор авторов.
Читать полностью »
Рассказ об уровне взаимодействия с хост-контроллерами растянулся на две статьи и всё равно оставил за кадром некоторые детали — которые, как я надеюсь, заинтересованный читатель может восполнить непосредственно из исходников. Уровень поддержки каналов куда проще и в основном занят тем, что преобразует вызовы API для вышележащих уровней в нужную последовательность действий, включая блокировки, с нужным хост-контроллером.
Функция USBOpenPipe из API, названная usb_open_pipe в коде pipe.inc, открывает новый канал по указанным характеристикам канала и «родительскому» каналу, где записаны характеристики устройства. Для этого она:
*hci_pipe+usb_pipe, описывающих канал и выравненных на контроллеро-специфичную границу, вызовом контроллеро-специфичной функции usb_hardware_func.AllocPipe;*hci_gtd+usb_gtd, описывающих пустой дескриптор передачи и выравненных на контроллеро-специфичную границу, вызовом контроллеро-специфичной функции usb_hardware_func.AllocTD;usb_hardware_func.InitPipe, охраняемую мьютексом, глобальным для контроллера;
Контроллеро-специфичная инициализация последним действием добавляет новый канал в соответствующий список. Для управляющих каналов, равно как и для каналов массивов данных, есть всего один список, а вот для каналов прерываний нужно ещё выбрать один из нескольких вариантов.
Здесь в игру вступает планировщик scheduler.inc. Он как раз и выбирает один из списков каналов прерываний, а также убеждается, что для нового канала «достаточно места». Я напомню, что в каждом фрейме FullSpeed-шины под периодические передачи нельзя использовать более 90% времени, а в каждом микрофрейме HighSpeed-шины — более 80% времени.
Здесь я должна отметить, что если вы зачем-то пишете реализацию USB, которая должна работать в ваших условиях, на планировщике можно серьёзно сэкономить. Вам придётся в том или ином виде реализовать всё остальное, что описано в этой серии статей, но при отсутствии большой нагрузки можно вместо полного дерева обойтись всего одним списком каналов прерываний, обрабатываемым каждый фрейм/микрофрейм. Чуть более экономная схема, не слишком усложняющая реализацию, — один список каналов для каждого интервала обработки 1, 2, 4, 8, 16, 32 фреймов. Пока не нужно одновременно обрабатывать более одного устройства с большим трафиком на один хост-контроллер, такой подход ничем не уступает полноценному планировщику. Простая схема «сломается» в некоторых специфичных конфигурациях с двумя или более изохронными каналами FullSpeed-устройств или тремя или более изохронными каналами HighSpeed-устройств, но, быть может, никто и не будет запускать вашу реализацию в столь специфичных условиях?
Если же вы пишете реализацию USB, которая должна работать везде и всегда, планировщик вам тоже придётся написать.
Читать полностью »
То, что в KolibriOS есть не-русскоговорящие разработчики (хоть их и очень мало), некоторым из вас уже известно по моему предыдущему посту. Однако разработчикам самим, в свою очередь, интересно знать, есть ли у нас не-русскоговорящие юзеры.
До того, как мы задались этим вопросом, KolibriOS выпускалась на 2 языках: русском и английском. Соответственно, каждая новая фича и каждая правка программы/ядра требовали от программиста, их делавшего, добавления/исправления всех сообщений, кнопок и лейблов на обоих языках.1 Может быть, целесообразно перестать выпускать английскую сборку, и сконцентрировать все свои усилия на русской?
Читать полностью »
Если кто-то из читателей ещё не знает, то, хотя большинство разработчиков KolibriOS русскоговорящие и живут в СНГ, у нас есть также несколько зарубежных разработчиков. Причём один из них, бельгиец Jeffrey Amelynck, нам больше известный под «ником» hidnplayr, участвует в проекте с 2003 года (ещё до того, как KolibriOS отделилась от MenuetOS — уже целых 10 лет!). С первых дней в проекте, он решил заниматься поддержкой сети и сетевыми программами, потому что на тот момент в MenuetOS с сетью было очень туго, если не сказать «вообще никак».
На фото — hidnplayr, с помощью собственноручно написанного FTP-client, подключается из-под KolibriOS к своему FTP-аккаунту на FTP-сервере KolibriOS. На заднем плане — файловый менеджер KFM для KolibriOS, написанный одним из основателей KolibriOS Mario_Z
Уровень поддержки хост-контроллеров, как я писала в общем обзоре, должен вызывать вышележащие уровни при наступлении некоторых событий и предоставлять функции, необходимые вышележащим уровням для работы.
Для удобства восприятия я буду рассказывать о различных элементах кода поддержки в том порядке, в котором они получают управление.
Подсистема USB запускается вызовом usb_init из init.inc в ходе загрузки системы.
К моменту запуска USB уже подготовлен список найденных PCI-устройств pcidev_list. USB-контроллеры опознаются среди всех PCI-устройств по коду класса, подкласса и интерфейса:
| Тип | Класс | Подкласс | Интерфейс |
|---|---|---|---|
| UHCI | 0Ch | 03h | 00h |
| OHCI | 0Ch | 03h | 10h |
| EHCI | 0Ch | 03h | 20h |
| XHCI | 0Ch | 03h | 30h |
usb_init проходит по списку PCI-устройств несколько раз, каждый раз выделяя USB-контроллеры.
Некоторые BIOS умеют обрабатывать USB-мыши, USB-клавиатуры и USB-флешки, предоставляя данные для операционных систем, не знающих про USB. Данные от мышей и клавиатур преобразуются в формат PS/2 и тем или иным способом доводятся до операционной системы так же, как если бы в системе существовала настоящая PS/2-мышь и/или клавиатура. USB-флешка представляется жёстким диском с точки зрения int 13h — такая поддержка встречается куда чаще поддержки мышей, ибо необходима для загрузки с флешек.
Операционная система может использовать любой режим процессора и самостоятельно обрабатывать любые прерывания. Чтобы BIOS в таких условиях всё же могла получать управление с предсказуемым окружением, ещё в районе 486-х (начиная со специальной версии i386SL, если точно) Intel придумала специальный режим процессора System Management Mode (SMM), в котором и работает BIOS, прерывая операционную систему. В SMM невозможно попасть средствами самого процессора; процессор попадает в этот режим, когда железо материнской платы подаёт специальный сигнал System Management Interrupt (SMI). USB-контроллеры, встроенные в чипсет, как правило, могут генерировать SMI вместо прерывания в зависимости от настроек.
Прежде, чем объяснять код поддержки хост-контроллеров, необходимо рассказать о некоторых принципах работы железа, а также об используемых структурах данных. Как я выяснила при написании текста, одна статья обо всём уровне поддержки хост-контроллеров получилась бы слишком большой, поэтому вторая часть цикла — которую вы сейчас читаете — рассказывает о том, что необходимо знать для понимания кода, а описание действий, происходящие в коде, я отложу до следующей части.
Хост-контроллеры оповещают софт о происходящих событиях, генерируя прерывания. Прерывание может прийти и оторвать процессор от текущей задачи в любой момент времени; это накладывает жёсткие требования на обработчик прерывания. Обработчик прерывания не может захватывать никакие блокировки — ведь вполне возможно, что прерванный код как раз завладел блокировкой и уже не сможет её освободить. Единственным исключением является вариант спинлока, запрещающий прерывания на время блокировки, но из-за глобальности эффекта спинлок стоит применять пореже и для очень коротких участков кода. На однопроцессорных конфигурациях такой вариант вырождается в пару cli/sti без собственно спинлока, на многопроцессорных внутри cli/sti остаётся обычный спинлок. Кроме того, контроллер прерываний во время обработки одного прерывания блокирует остальные с тем же или более низким приоритетом.
По этим двум причинам в KolibriOS обработчики прерываний от хост-контроллеров USB передают основную часть работы в выделенный под USB поток ядра, а сами ограничиваются сообщением хост-контроллеру «спасибо, сигнал принят». Сам USB-поток имеет наивысший приоритет, чтобы задумавшиеся пользовательские приложения не мешали обработке. Все функции вышележащих уровней, которые вызываются из уровня поддержки хост-контроллера, работают в контексте потока USB и, как следствие, вполне могут использовать примитивы синхронизации. Приятным побочным эффектом является автоматическая сериализация вызовов: ни обработчик завершения второй передачи из очереди канала, ни функция DeviceDisconnected не будут вызваны, пока не закончит работу обработчик завершения первой передачи из очереди канала, что есть логичное требование к API.
Поток USB также иногда просыпается для обработки событий, отложенных по времени. Пример, о котором я позже расскажу подробнее: после события подключения устройства нужно выждать 100 миллисекунд перед дальнейшей обработкой. В этом случае поток проснётся при обнаружении подключения устройства и запланирует следующее пробуждение через 100 миллисекунд, уже не связанное с пробуждением из-за прерывания.
Читать полностью »
Для тех, кто интересуется проектом KolibriOS, у нас очень хорошая новость — ровно 1 неделю назад в нашем проекте в ночных сборках появилась поддержка USB. В лучших традициях проекта, код полностью написан на ассемблере FASM. Причём он всё ещё влазит на одну дискету занимает 1MB, включая программы и игры. И, в отличие от нашего прародителя MenuetOS, у нас даже работает USB hot-plug. Разработчики QNX Demo Disk нервно курят в сторонке.
Читать полностью »
KolibriOS — открытая операционная система, написанная русской командой разработчиков исключительно на языке ассемблера, и требующая всего 8 МБ для запуска. Её дистрибутив занимает одну 1.44 МБ-дискету и, тем не менее, включает в себя текстовый редактор, программу для просмотра изображений, браузер, набор из 30+ игр, различные тесты, системные и прикладные утилиты. Полностью поддерживается FAT12/16/32, в режиме чтения — NTFS, ISO9660 и Ext2/3/4. Написаны драйверы для популярных звуковых, сетевых и графических карт.
В этом году администраторы проекта подали заявку участие в Google Summer of Code 2013, но их предложение было отвергнуто. Причем Google написали, что им нравится проект, но из-за ограниченного бюджета они не могут принять всех из 416 претендентов. Поскольку список нововведений KolibriOS, которые планировалось реализовать на GSoC '13, довольно обширный, и уже внесен в некотором смысле в планы разработки, было решено организовать свой SOC. Поскольку проект некоммерческий, а на донейтной основе маленькому проекту пока что сложно быстро собирать финансирование, разработчики выбрали Kickstarter. Кампания была запущена 3 дня назад, из £5,000 пока что собрано свыше 10%. Сбор средств закончится 31 мая.
Вы можете скачать KolibriOS и решить, стоит ли поддерживать проект, на этой странице: kolibrios.org/ru/download.htm
Адрес Kickstarter-кампании: www.kickstarter.com/projects/kolibrios/kolibrios-help-us-hold-our-own-summer-of-code-2013
Читать полностью »