Только что был опубликован список open-source организаций, участвующих в Google Summer of Code 2014. Google Summer of Code (сокращённо GSoC) впервые состоялся в 2005 году, а в этом году проводится в юбилейный, 10-й раз. В честь юбилея, Google обещал, что в этом году примет на 10 организаций больше, чем когда-либо в прошлом, и на 10% больше студентов, чем когда бы то ни было. Таким образом, в этом году были отобраны 190 open-source организаций (так как максимальное число принятых организаций составляло 180 в 2012 году).

Студенты, желающие принять участие в GSoC, могут начать знакомиться со списком организаций. Приём заявок от студентов в этом году начнётся 10 марта, и окончится 21 марта. Подробнее о GSoC (с точки зрения студента) можно прочитать в этом топике. Единственная разница с прошлыми годами — размер стипендии для студентов увеличили, и теперь она составляет 5,500$ США.

Многие люди задаются вопросом: «Можно ли написать программу на Си под KolibriOS?»
Ответ: «Да, можно!», и ниже я расскажу, как это сделать.


Для написания программы, нам понадобятся:

• Компьютер или виртуальная машина с KolibriOS (если у Вас не установлена KolibriOS, её можно скачать с нашего сайта). Напомню, что KolibriOS для работы требует минимум 8MB RAM и Pentium-совместимый CPU.
• Флешка (если Вы пишете код не в самой Колибри).
• Компилятор TCC (Tiny C Compiler). Сборку для Колибри (mini_c_dev) можно скачать на нашем форуме. Тема с обсуждением ktcc (Kolibri TCC) находится здесь: board.kolibrios.org/viewtopic.php?f=45&t=565

Всем известно, что для наиболее эффективного решения всех проблем Вашего софта, необходимы грамотный баг-репорт и соответствующие логи. Но, зачастую, пользователи не предоставляют исчерпывающую и качественную информацию об ошибках, так что приходится обходиться тем, что есть. Так произошло и в этом случае: некий юзер mdickie прислал скриншот лога, хранивший в себе тайну зависания нашей ОС на его компьютере. Но фото оказалось крайне низкого качества, так что часть текста можно было разобрать с трудом, а остальной текст — невозможно разобрать вообще. yogev_ezra попробовал улучшить качество с помощью программ обработки изображений, но почти безуспешно.

Тогда мы решили провести конкурс на Хабре, суть которого заключалась в том, что любой читатель Хабра может попытаться улучшить оригинальную смазанную фотографию с помощью любой программы обработки изображений, и опубликовать свой результат. Читателя, добившегося наилучшего результата, ждёт приз — фирменная флешка и футболка с логотипом KolibriOS (включая пересылку на указанный победителем адрес). Обработанные фотографии надлежало выкладывать в комментариях к посту с конкурсом, либо на нашем форуме (в той теме, где находилась оригинальная фотография), до 17 сентября 2013 года 24:00 GMT. (Осторожно, трафик — под катом много фото)

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

Если вам интересна KolibriOS и её развитие, но вы не имеете возможности следить за нововведениями на форуме (что бывает иногда трудно, особенно если вы только недавно начали интересоваться), то эта статья именно для вас. Это первая статья из серии ежемесячных дайджестов, направленных на освещение событий в сообществе ОС. Дайджесты будут выходить в последний рабочий день месяца. Поскольку это первая статья, то в ней, для налаживания линии информирования, будут рассмотрены изменения за промежуток времени более месяца. Хочу подчеркнуть, что особенно крупные изменения по-прежнему будут освещаться в отдельных статьях. Ну что ж, приступим.

Последняя часть инфраструктуры 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 в ответ на отключение устройства.

В первой части статьи я рассказал о компании DMP Electronics, малоизвестном тайваньском производителе x86-совместимых процессоров семейства Vortex86, а также материнских плат и компьютеров на их базе. Во второй части я обещал привести сравнительные характеристики процессора Vortex86MX, и сделать обзор компьютера eBox-3300MX на его базе. К сожалению, по не зависящим от меня причинам, вторая часть ещё не закончена, и я вынужден опубликовать третью часть раньше второй. В третьей части речь пойдёт об Arduino.

UPD 15/01/2014: Производитель попросил сообщить, что доставка в Россию будет, и не нужно спрашивать об этом по e-mail. К сожалению, производство задерживается на 2-3 недели по техническим причинам, и товар появится на складе во 2-ую неделю февраля.

Не прошло и месяца, как Intel объявила о начале продаж первого x86-совместимого Arduino-контроллера, а DMP Electronics уже выпустила свою версию платы на базе своего собственного процессора Vortex86EX. Новая плата получила название 86Duino. (Нажмите на фото для увеличения — осторожно, трафик!)

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

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

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

Встречайте корпоративного юзера блога 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

Существуют разные способы «монетизировать» проект. Но у них есть одна общая составляющая ― то, как деньги переходят из кошелька пользователя на счет организации. Сегодня мы расскажем о том, как организован прием платежей в Badoo и что можно встретить на рынке платежных шлюзов. Сразу предупреждаем, что в статье вы не найдете конкретных цифр по обороту средств компании, но все остальное будет не менее интересно.

Что такое «биллинг»

Для нас биллинг ― это всё, что связано с получением денег от пользователей: конфигурация цен, страница приема платежей, непосредственно прием и обработка платежей, оказание оплаченных услуг, различные промоакции и, конечно же, мониторинг всего вышеописанного.

Несколько дней назад, на форуме 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 в текстовый файл не получится, и в таких случаях мы просим сфотографировать лог с экрана монитора на смартфон или фотоаппарат, и выложить фото на нашем форуме. И здесь мы переходим ко второй части статьи.

Глава первая, Глава вторая, Глава третья, Глава четвертая, Глава пятая, Эпилог

Disclaimer

Если мы редактируем игру, то мы должны привести все ее детали в соответствие. Было бы глупо свою версию игры показывать миру, если в ней вылезают осколки оригинальной версии, вступая в противоречие с новым, вложенным в нее нами смыслом. Редактирование уровней игры не позволяет поменять некоторые повороты сюжета, которые вложили разработчики изначально.

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

В игре Prehistorik 2 не предусмотрены сейвы, но на каждом уровне есть (болтается в воздухе в некотором месте уровня) код уровня. Есть два режима прохождения, Beginner и Expert, код также определяет режим. При старте игры можно начать с первого уровня, а можно ввести код и попасть сразу на соответствующий уровень. На одном и том же компьютере с неизменным окружением коды не меняются, но на разных компьютерах коды, вообще говоря, разные, так что коды, найденные при прохождении и тщательно выписанные на бумажку, станут совершенно бесполезны в другом окружении. Поэтому вместо бумажки лучше иметь программу, которая пишет коды для конкретного окружения. Готовый результат: genpass.com, представляет из себя DOS-программу, которая должна запускаться в том же окружении, что и игра. Альтернативный вариант попасть на нужный уровень из экрана ввода кода: ввести три кода ADDE C0DE F00D либо DEAD C0DE F00D, каждый из трёх кодов сам по себе неверен, но при вводе их в таком порядке четвёртый код — номер уровня от 1 до 10, плюс 10 для режима Expert, приводит сразу на запрошенный уровень.

Под катом — процесс исследования. Требуется знание ассемблера x86 хотя бы на уровне «читаю со словарём».

Рассказ об уровне взаимодействия с хост-контроллерами растянулся на две статьи и всё равно оставил за кадром некоторые детали — которые, как я надеюсь, заинтересованный читатель может восполнить непосредственно из исходников. Уровень поддержки каналов куда проще и в основном занят тем, что преобразует вызовы 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, которая должна работать везде и всегда, планировщик вам тоже придётся написать.

Это перевод поста, опубликованного в англоязычном блоге «Лаборатории Касперского».
Он не столько о вирусах, сколько о демосцене и лучших произведениях в этом жанре искусства.

Недавно Евгений Касперский опубликовал в своем блоге запись «Призраки вирус-оперы, или Ситхи Ассемблера», посвященную сверхкомпактным и мощным вредоносным приложениям, обнаруженным недавно, но написанным в стиле 15-летней давности. Мой возраст позволяет помнить этих парней и их блестящую работу – речь ведь не обязательно о создателях вирусов, они были лишь частью программистского сообщества, специализировавшегося на «ручном» написании кода и программировании на ассемблере. Это похоже на Джедаев и Ситхов из мира «Звездных войн» – существ, чье оружие, лазерные мечи, было крайне специфическим и, несмотря на это, воспринималось всеми остальными героями как одно из самых мощных (кроме шуток, спросите Йоду). Увы, похоже, людей, которые помнят этих мастеров-программистов, осталось трое (я, Касперский и Билл Гейтс). А если серьезно – в сегодняшнем мире, где драйвер мышки занимает 50 мегабайт, довольно трудно вообразить, на что способен хакер старой школы при совсем небольшом количестве выделенных ресурсов. Поэтому я решил показать, о чем говорит Евгений, на несколько ином примере – а вы уж решайте, насколько плохи новости об «олдскульных» авторах заразы.

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


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

Формат архивов 7-Zip довольно гибкий и позволяет, например, включать весь архив как один из файлов внутри самого архива, лишь немного считерив. Разберём формат на примере: создадим почти вручную архив с именем «Рекурсивный.7z», содержащий два файла: «Какой-то файл.txt» с содержимым «Hello, Habrahabr!» и «Рекурсивный.7z», копию самого себя.

Краткая документация по формату входит в LZMA SDK. Архив начинается со следующей структуры размером 32 байта. Все позиции внутри архива кодируются как смещения относительно конца этой структуры.

сигнатура, 6 байт: { '7', 'z', 0xBC, 0xAF, 0x27, 0x1C };
версия формата, два байта { Major, Minor }, 7-Zip 9.20 пишет сюда { 0, 3 };
CRC следующих трёх полей, 4 байта;
смещение основного заголовка относительно конца этой структуры, 8 байт;
размер основного заголовка, 8 байт;
CRC основного заголовка, 4 байта.

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

Основной заголовок может быть сам по себе упакован (а также зашифрован). Поскольку он содержит структурированные данные (типа имён файлов), коэффициент сжатия достаточно неплохой. Именно для возможности подобного сжатия вся информация о файлах в 7z собрана в одном заголовке и полностью отделена от сжатых данных файлов. Признак упакованности — первый байт основного заголовка: он должен быть равен 1 у неупакованного заголовка и 0x17 у упакованного. Для создания архива вручную мы не будем ничего сжимать.

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

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