Пожалуй, самый частый вопрос, который разработчики KolibriOS слышат в свой адрес: "Когда вы собираетесь портировать Колибри на ARM?" Мы всегда отвечаем, что это невозможно, KolibriOS написана на ассемблере FASM с использованием инструкций x86, и портирование её на ARM будет означать практически полное переписывание с нуля. Но главная причина в том, что на рынке есть достаточно компьютеров на x86-совместимых процессорах, размером как Raspberry Pi и стоимостью всего на $5-$35 дороже, а это делает портирование не только невозможным, но также и бесполезным занятием. Чтобы читатели не говорили, что x86-совместимый компьютер за $40 — это «сферический конь в вакууме», я решил написать обзорный цикл из 3 статей о нескольких таких компьютерах. Сразу оговорюсь, что статьи не спонсируются — всё это железо я покупал на свои деньги, и на части него я практически каждую неделю тестирую Колибри — не стала ли она, случаем, слишком медленной? Кому интересно — прошу под кат.

Последняя часть инфраструктуры USB — хабы. Хотя хабы — отдельные USB-устройства, они достаточно тесно связаны с другими частями инфраструктуры, чтобы спецификация хабов была частью основной спецификации USB, а код поддержки — частью ядра, расположенной в файле bus/usb/hub.inc.

Задачи хабов таковы.

• Хабы предоставляют питание всем подключённым устройствам.
• Хабы оповещают хост о подключении и отключении устройств.
• Хабы делают сброс подключённого устройства, попутно определяя его скорость, по команде с хоста.
• Хабы транслируют весь трафик, приходящий от хоста, подключённым устройствам в период после сброса и до отключения, а также трафик от устройств в обратную сторону.
• HighSpeed-хабы содержат Transaction Translator, связывающий HighSpeed-шину с низкоскоростной USB1-шиной.

Трансляция трафика без переключения скорости происходит полностью прозрачно для хоста. Расщеплёнными транзакциями занимается хост-контроллер EHCI, здесь от софта важно только заполнить те поля в аппаратной части структуры канала, которые содержат адрес TT-хаба и порт в TT-хабе — и, разумеется, учитывать время транзакций при планировании. Драйвер хабов управляет остальными пунктами списка задач.


Хабы имеют код класса устройства 9, код подкласса устройства 0 и три варианта 0, 1, 2 для кода протокола. Согласно спецификации USB, HighSpeed-хаб обязан поддерживать режим работы с единым TT для всех своих портов, и дополнительно может, но не обязан, поддерживать режим работы с отдельным TT для каждого порта. Типичный случай — режим с различными TT отсутствует, тогда код протокола равен 0. В случае поддержки такого режима в данных конфигурации должны быть два варианта дескриптора интерфейса с одинаковым номером интерфейса. Тогда код протокола 1 идентифицирует режим с единым TT, который должен быть принят по умолчанию, а код протокола 2 — режим с различными TT, включаемый командой SET_INTERFACE. Существование в живой природе хабов, поддерживающих режим с различными TT, не подтверждено, как и польза от этого режима, поэтому драйвер хабов даже не пытается его обнаружить и включить и просто использует режим единого TT, включённый по умолчанию.

Обнаружив интерфейс класса 9, уровень логического устройства читает структуру usb_hub_callbacks, содержащую указатели на функции драйвера usb_hub_init и usb_hub_disconnect. Работа драйвера начинается, когда уровень логического устройства вызывает usb_hub_init, и заканчивается, когда уровень поддержки каналов вызывает usb_hub_disconnect в ответ на отключение устройства.

Исходники эмулятора x86 на JavaScript опубликованы около 1 часа назад на GitHub под лицензией BSD: github.com/copy/v86, а также доступны для скачивания в архиве tar.gz: copy.sh/v24/v86-latest.tar.gz

В самом эмуляторе на сайте автора теперь можно запустить, помимо уже существующих KolibriOS, Linux 2.6, FreeDOS и OpenBSD, также Windows 1.01, и даже поиграть в Reversi (правда, доступна только одна дискета):

Обработка подключения устройства, начатая на уровне поддержки хост-контроллеров, остановилась, подготовив нулевую конечную точку устройства к работе. Уровень поддержки каналов предоставил методы работы с каналами. Самое время их применить для продолжения инициализации устройства: включается функция usb_new_device из bus/usb/protocol.inc.

Сейчас устройство мало что может: оно ещё не получило адрес на шине, ещё не сконфигурировано, может использовать только 100 мА питания от шины. В общем-то, всё, что устройство может, — это рассказать о себе в ответ на подходящие вопросы. Рассказ устройства о себе организован в виде дескрипторов. Подходящим вопросом считается команда GET_DESCRIPTOR, отправленная нулевой конечной точке; в команде должны быть указаны тип дескриптора, порядковый номер дескриптора среди всех с таким типом, длина данных для передачи. Каждая команда к управляющей конечной точке занимает 8 байт и может иметь или не иметь дополнительных данных, в некоторых командах некоторые поля не используются. Структура команд по байтам и используемые поля расписаны в главе 9 спецификации USB, здесь я буду только описывать входные и выходные данные для команд.

Уровень логического устройства имеет две задачи: во-первых, сконфигурировать устройство; во-вторых, расспросить его, загрузить соответствующий драйвер — или даже драйверы — и сообщить драйверу о новом устройстве.

Сегодня, 21 октября 2013 г., формально окончился KSoC (KolibriOS Summer of Code). Изначально было запланировано, что он завершится 17 сентября, но ввиду непредвиденных обстоятельств, пришлось продлить его на один месяц (а потом ещё на несколько дней, до следующего понедельника, то есть, до сегодняшнего дня).

В KSoC участвовали 2 студента, и результатом их работы стало:
1. Появление поддержки файловой системы XFS (только чтение)
2. Поддержка записи для файловой системы Ext2 (поддержка чтения была)
Теперь из KolibriOS можно будет редактировать файлы, хранящиеся на дисках в компьютерах, работающих под управлением Linux (Ext2/3/4).

Встречайте корпоративного юзера блога KolibriOS. От имени этого юзера будут публиковаться статьи, написанные авторами-фрилансерами в рамках «Блог KolibriOS ищет авторов», а также участниками проекта, не имеющими пользователя на Хабре, либо не желающими по какой-либо причине публиковать статьи от своего имени.

В качестве первой публикации, предлагаем Вашему вниманию интервью с Сергеем Кузьминым (ник Wildwest), одним из «старожилов» в проекте KolibriOS (на Хабре W__W).

1. Расскажите о себе, кто Вы и откуда? Чем занимаетесь?

Я преподаю в одном из вузов Санкт-Петербурга — веду лабораторные и практикумы, читаю лекции. В науке занимаюсь алгоритмами автоматического анализа видеоинформации для систем компьютерного зрения и прикладного телевидения. Написал больше 40 статей, в прошлом году стал соавтором монографии. С открытия Coursera (весна 2012) слежу за курсами по технике и ИТ: некоторые просто скачиваю в надежде когда-нибудь посмотреть, а на других учусь — получил сертификаты от трех профессоров в области компьютерного зрения — Jitendra Malik, Guillermo Sapiro, Irfan Essa.

2. Как долго Вы в этом проекте?

Я узнал о ней (MenuetOS — прим. редактора) из печатной версии статьи www.comprice.ru/articles/detail.php?ID=43137 во второй половине июля 2003 года.

Через несколько недель я вышел в интернет, зашел на menuet.narod.ru, скачал разные дистрибутивы. Первым я решил запустить немецкий дистрибутив Gerschi (menuet.narod.ru/arch2003_3.htm). Выглядел он очень красочно.

Сегодня, ровно через месяц после того, как это сделали наши старшие братья, команда разработчиков 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 ограничения:

1. Доступ к дискам через «костыль» BIOS очень медленный, поэтому фильм с такого диска в KolibriOS не посмотришь — будет идти рывками. Скорость копирования файлов тоже неприемлемая — можно пообедать, пока копируется большой файл.
2. Некоторые диски без драйвера вообще никак не видны в системе.

Ввиду этого, на сегодняшний момент у нас пишутся 2 драйвера SATA (параллельно):

• Драйвер для контроллера SATA в режиме IDE от Mario_Z: board.kolibrios.org/viewtopic.php?f=1&t=2343
• Драйвер для контроллера SATA в режиме AHCI от Serge: board.kolibrios.org/viewtopic.php?f=31&t=2152

Оба драйвера имеют одну неприятную особенность — наглухо подвешивать систему в случае любой нештатной ситуации — и тогда требуются логи, чтобы увидеть конфигурацию дисков и попытаться узнать причину зависания. Именно это и произошло у mdickie, и поэтому я попросил его приложить логи. Естественно, при зависании всей системы скопировать логи прямо из KolibriOS в текстовый файл не получится, и в таких случаях мы просим сфотографировать лог с экрана монитора на смартфон или фотоаппарат, и выложить фото на нашем форуме. И здесь мы переходим ко второй части статьи.

Так уж получилось, что, кроме меня и CleverMouse, ни у кого из членов проекта KolibriOS, присутствующих на Хабре, нет свободного времени (желания, умения — нужное подчеркнуть) писать статьи в наш блог. Мы двое, параллельно работая на основной работе, не можем уделять блогу достаточно времени, чтобы статьи появлялись регулярно хотя бы раз в неделю (напомню, что занятие KolibriOS — для нас всего лишь хобби, и вся работа над этой операционной системой ведётся на добровольных началах).

Как вы могли заметить, новых статей в блоге не было уже больше месяца, потому что последний месяц мы оба заняты на работе больше обычного. Я даже всё не могу дописать обещанные 2 статьи про Кикстартер. И мне очень жаль, что такая хорошая вещь пропадает блог простаивает.

Поэтому я решил попытать счастья на бирже авторов (это разрешено на Хабре). Любой пользователь, желающий писать статьи в блог KolibriOS, может связаться со мной посредством личного сообщения на Хабре, либо на нашем форуме, или просто написать комментарий в этом топике и предложить свою кандидатуру, и тогда я свяжусь с ним сам. Писать можно будет о чём угодно — главное, чтобы это было как-то связано с 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-контроллеров происходит в потоке USB, про обращения к API нельзя сказать того же: чтение приложением файла с USB-флешки инициирует постановку передачи — и даже не одной — в очередь в контексте потока приложения. Чтобы новая передача не мешала USB-потоку обрабатывать завершение старой передачи, и нужен этот мьютекс;
• захватывает мьютекс набора каналов устройства и убеждается, что устройство ещё не отключено;
• вызывает контроллеро-специфичную инициализацию usb_hardware_func.InitPipe, охраняемую мьютексом, глобальным для контроллера;
• добавляет новый канал в набор каналов устройства и отпускает мьютекс набора каналов;
• при ошибке на одном из этапов откатывает все предыдущие этапы. Поскольку откатить контроллеро-специфичную инициализацию сложнее всего, она сделана на последнем этапе, после которого ошибок быть не может.

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

Здесь в игру вступает планировщик scheduler.inc. Он как раз и выбирает один из списков каналов прерываний, а также убеждается, что для нового канала «достаточно места». Я напомню, что в каждом фрейме FullSpeed-шины под периодические передачи нельзя использовать более 90% времени, а в каждом микрофрейме HighSpeed-шины — более 80% времени.

Здесь я должна отметить, что если вы зачем-то пишете реализацию USB, которая должна работать в ваших условиях, на планировщике можно серьёзно сэкономить. Вам придётся в том или ином виде реализовать всё остальное, что описано в этой серии статей, но при отсутствии большой нагрузки можно вместо полного дерева обойтись всего одним списком каналов прерываний, обрабатываемым каждый фрейм/микрофрейм. Чуть более экономная схема, не слишком усложняющая реализацию, — один список каналов для каждого интервала обработки 1, 2, 4, 8, 16, 32 фреймов. Пока не нужно одновременно обрабатывать более одного устройства с большим трафиком на один хост-контроллер, такой подход ничем не уступает полноценному планировщику. Простая схема «сломается» в некоторых специфичных конфигурациях с двумя или более изохронными каналами FullSpeed-устройств или тремя или более изохронными каналами HighSpeed-устройств, но, быть может, никто и не будет запускать вашу реализацию в столь специфичных условиях?

Если же вы пишете реализацию USB, которая должна работать везде и всегда, планировщик вам тоже придётся написать.

То, что в KolibriOS есть не русскоговорящие разработчики (хоть их и очень мало), некоторым из вас уже известно по моему предыдущему посту. Однако разработчикам самим, в свою очередь, интересно знать, есть ли у нас не русскоговорящие юзеры.

До того, как мы задались этим вопросом, KolibriOS выпускалась на 2 языках: русском и английском. Соответственно, каждая новая фича и каждая правка программы/ядра требовали от программиста, их делавшего, добавления/исправления всех сообщений, кнопок и лейблов на обоих языках.¹ Может быть, целесообразно перестать выпускать английскую сборку, и сконцентрировать все свои усилия на русской?

Если кто-то из читателей ещё не знает, то, хотя большинство разработчиков KolibriOS русскоговорящие и живут в СНГ, у нас есть также несколько зарубежных разработчиков. Причём один из них, бельгиец Jeffrey Amelynck, нам больше известный под «ником» hidnplayr, участвует в проекте с 2003 года (ещё до того, как KolibriOS отделилась от MenuetOS — уже целых 10 лет!). С первых дней в проекте он решил заниматься поддержкой сети и сетевыми программами, потому что на тот момент в MenuetOS с сетью было очень туго, если не сказать «вообще никак».


На фото — hidnplayr, с помощью собственноручно написанного FTP-client, подключается из-под KolibriOS к своему FTP-аккаунту на FTP-сервере KolibriOS. На заднем плане — файловый менеджер KFM для KolibriOS, написанный одним из основателей KolibriOS Mario_Z

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

Запуск подсистемы USB

Подготовка: USB-контроллеры в списке PCI-устройств

Подсистема 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

Некоторые 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 миллисекунд, уже не связанное с пробуждением из-за прерывания.

Архитектура USB содержит несколько уровней. На самом низком уровне специально обученное железо, называемое хост-контроллером (host controller), общается с USB-устройством специальными сигналами. Сигналы кодируют биты, биты складываются в пакеты, пакеты образуют транзакции, транзакции составляют передачи (transfers).

Я рассказываю о программной поддержке USB, поэтому уровни ниже передач почти неинтересны: за них отвечает хост-контроллер. Зато важно, какой интерфейс представляет хост-контроллер софту. Сейчас распространены три интерфейса, и постепенно распространяется четвёртый:

Аббр.	Название интерфейса	Версия	Код поддержки контроллера в KolibriOS
UHCI	Universal Host Controller Interface	USB 1.1	kernel/trunk/bus/usb/uhci.inc
OHCI	Open Host Controller Interface	USB 1.1	kernel/trunk/bus/usb/ohci.inc
EHCI	Enhanced Host Controller Interface	USB 2.0	kernel/trunk/bus/usb/ehci.inc
XHCI	eXtensible Host Controller Interface (новый)	USB 3.0	В KolibriOS ещё не поддерживается

На этом же уровне взаимодействия с контроллерами находятся файлы kernel/trunk/bus/usb/hccommon.inc, где реализованы некоторые функции, общие для всех контроллеров, и kernel/trunk/bus/usb/init.inc, который запускает всю подсистему. Впрочем, не торопитесь пока лезть в код — во-первых, я ещё не рассказала про то, чего же ожидают от него более высокие уровни, а во-вторых, после демонстрации общей схемы я вернусь к отдельным компонентам с подробностями.

Для тех, кто интересуется проектом KolibriOS, у нас очень хорошая новость — ровно 1 неделю назад в нашем проекте в ночных сборках появилась поддержка USB. В лучших традициях проекта, код полностью написан на ассемблере FASM. Причём он всё ещё помещается на одну дискету занимает 1MB, включая программы и игры. И, в отличие от нашего прародителя MenuetOS, у нас даже работает USB hot-plug. Разработчики QNX Demo Disk нервно курят в сторонке :-)

Всё началось с новости о возможном представлении KolibriOS на для Chaos Constructions-2011. Она была опубликована на форуме разработчиков KolibriOS за четыре месяца до мероприятия.

И вот, в начале августа 2011 года у меня возникла идея создать образ для виртуальной машины с этой системой (KolibriOS), разнообразным программным обеспечением и примерами файлов, с которым можно работать. Собственно, этим я и занялся.

Завершилась работа над выпуском новой версии. С полным списком изменений можно ознакомиться здесь. Скачать систему можно c сайта KolibriOS.

UPD: В связи с хабраэффектом сайт системы открывается через раз, поэтому для разгрузки хабраюзер fzfx создал зеркало, за что ему персональное спасибо.