Сегодня, 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

В последнее время, количество новостей связанных с блокировками зашкаливает.

Но куда уходить людям?

Что бы был доступ к информации, свобода слова и соблюдались хотя бы те правила, которые есть в конституции?

Mesh сети не подходят, Tor — тоже не может обеспечить требуемого, остается I2P.

Сегодня мы поговорим как настроить прозрачный доступ в I2P, с помощью которого каждая домохозяйка сможет открыть любой сайт в этой сети.

    Наверняка многие из нас хоть раз думали про себя: «Черт побери, и везет же этим американцам!». Это касается многого, от магазинов с доставкой «только в пределах 48 континентальных штатов» до вполне серьезных контрактов, которые срываются только потому, что потенциальный заказчик в США категорически не желает иметь дело с иностранцами.

    В этой статье я попробую осветить процесс создания и администрирования американской корпорации для резидента РФ. Наверняка многие из фактов для самих американцев покажутся тривиальными, однако для жителя России все куда сложнее — увы, это данность. Чтоб не сказать — это Родина, сынок. Оговорюсь сразу — я все это проделал более 2 лет назад, так что, некоторые детали могут быть не совсем актуальны. Но вряд ли что-то поменялось принципиально.

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

«Право налогоплательщика избегать уплаты налогов с использованием всех разрешенных законом способов никем не может быть оспорено. Каждый имеет право вести свои финансовые дела таким образом, чтобы свести соответствующие платежи к минимуму…»
Дж. Сандерленд,
Судья Верховного Суда США

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

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

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

Прерывания и потоки

Хост-контроллеры оповещают софт о происходящих событиях, генерируя прерывания. Прерывание может прийти и оторвать процессор от текущей задачи в любой момент времени; это накладывает жёсткие требования на обработчик прерывания. Обработчик прерывания не может захватывать никакие блокировки — ведь вполне возможно, что прерванный код как раз завладел блокировкой и уже не сможет её освободить. Единственным исключением является вариант спинлока, запрещающий прерывания на время блокировки, но из-за глобальности эффекта спинлок стоит применять пореже и для очень коротких участков кода. На однопроцессорных конфигурациях такой вариант вырождается в пару 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), разнообразным программным обеспечением и примерами файлов, с которым можно работать. Собственно, этим я и занялся.