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

Про кэш процессоров написано много, в том числе и на Хабре, но все больше общими словами. Предлагаю вашему вниманию конкретный пример того, как работает кэш в реальной жизни.

В качестве примера я возьму простенькую систему на кристалле, основанную на 32-битном гарвардском RISC-процессоре с одноуровневой кэш-памятью и без MMU (что-то типа ARM Cortex-R). Процессор подключен к контроллеру внешней памяти через 32-битную шину AMBA AHB, работающую на частоте процессора.

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

Формат архивов 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 у упакованного. Для создания архива вручную мы не будем ничего сжимать.

Наверняка многие, кто заказывал товар из-за границы, задавались вопросом: что происходит с посылками от экспорта до импорта? В каком потустороннем пространстве они иногда проводят месяцы своего путешествия? Какими самолетами прилетают в Новосибирск посылаемые авиапочтой в Москву отправления?

Идея

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

Один мой друг послал почтой другому моему другу…

Привет!

Пришло время раздавать железо!

Мы раздадим:
1. SuperMicro 2x3.0 GHz, 12GB RAM, W/O HDD, SCSI.
2. SuperMicro 2x3.0 GHz, 12GB RAM, W/O HDD, SCSI.
3. SuperMicro 2x3.0 GHz, 12GB RAM, W/O HDD, SCSI.
4. SuperMicro 2x3.0 GHz, 12GB RAM, W/O HDD, SCSI.
5. SuperMicro 2x3.0 GHz, 12GB RAM, W/O HDD, SCSI.
6. SuperMicro 2x3.0 GHz, 12GB RAM, W/O HDD, SCSI.
7. SuperMicro 2x3.0 GHz, 12GB RAM, W/O HDD, SCSI.
8. SuperMicro 2x3.0 GHz, 12GB RAM, W/O HDD, SATA.
9. SuperMicro 2x3.0 GHz, 12GB RAM, W/O HDD, SATA.
10. SuperMicro 2x3.0 GHz, 12GB RAM, W/O HDD, SATA.
11. SuperMicro 2x3.0 GHz, 12GB RAM, W/O HDD, SATA.
12. SuperMicro 2x3.0 GHz, 12GB RAM, W/O HDD, SATA.
13. SuperMicro 2x3.0 GHz, 12GB RAM, W/O HDD, SATA.
14. MSI Eximer Glodiatr 1x2.0Ghz(2 сокета, 1 свободен), 4GB, W/O HDD, IDE hotswap
15. HP DL160 1xXeon 2GB, W/O HDD, IDE
16. Intel SR1200 2x1.4GHz(PIII, пентиум!), 4GB, W/O HDD, SCSI
17. SuperMicro 50135-8 2x2.0GHz(Xeon 32bit), 4GB, W/O HDD, SCSI
18. SuperMicro 2x2.0GHz(Quad) W/O RAM, W/O HDD
19. SuperMicro 2x2.0GHz(Quad) W/O RAM, W/O HDD
20. Intel SR2400 2x3.0Ghz(Xeon), 6GB, SATA 2U
21. Intel SR1400 2x3.0Ghz(Xeon), 6GB, SATA

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

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

Всем доброго времени суток! Я студентка-второкурсница технического ВУЗа. Пару месяцев назад пришла пора выбирать себе тему курсового проекта. Темы типа калькулятора меня не устраивали. Поэтому я поинтересовалась, есть ли что-нибудь более интересное, и получила утвердительный ответ. «Подмена обработчика системного вызова» — вот моя тема.

Введение

Обработчик прерываний (или процедура обслуживания прерываний) — специальная процедура, вызываемая по прерыванию для выполнения его обработки. Эти обработчики вызываются либо по аппаратному прерыванию, либо соответствующей инструкцией в программе, и обычно предназначены для взаимодействия с устройствами или для осуществления вызова функций операционной системы (wiki).

Зачем?

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

Готовь сани летом, а телегу зимой. Копиразм крепчает. А значит самое время готовится к трудным временам, и позаботиться о создании альтернативной Windows-совместимой операционной системы. Поэтому команда проекта ReactOS c гордостью представляет очередной релиз:

ReactOS 0.3.15

Наиболее значимые нововведения этого выпуска:

• «Расово верная» реализация поддержки USB-мыши, клавиатуры и устройств хранения данных.
• Переписана подсистема управления сессиями.
• Alternate ReactOS Memory Management Module взял на себя все практически обязанности управления памятью.
• Обновленный драйвер UniATA с поддержкой SATA-1/2/AHCI.
• Предварительная поддержка для отладки компонентов ReactOS с помощью WinDbg.
• Virtual PC (и потенциально Hyper V) возвращена в список поддерживаемых платформ виртуализации (если не считать бага с видеодрайвером).
• Различные улучшения благодаря внедрению набора тестов приложений на основе AutoHotKey.
• Багфиксы по результатам сканирования утилитой Driver Verifier встроенных в дистрибутив драйверов.

Скачать дистрибутивы можно здесь

Архитектура 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 — открытая операционная система, основанная на MenuetOS (форк произошел в 2004 году), требующая всего 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 пока что собрано свыше 20%. Сбор средств закончится 31 мая.

Вы можете скачать KolibriOS и решить, стоит ли поддерживать проект, на этой странице: kolibrios.org/ru/download.htm
Адрес Kickstarter-кампании: www.kickstarter.com/projects/kolibrios/kolibrios-help-us-hold-our-own-summer-of-code-2013

Один из программистов компании Microsoft анонимно выступил на форуме Hacker News и выдал интересные подробности о процессе разработки ядра NT. Своим сообщением он хотел подтвердить тезис о том, что ядро неэффективно и во многом уступает по производительности другим ОС: см. оригинальное сообщение (автор удалил его, испугавшись резких формулировок) и копию.

Причина проблем, по словам сотрудника Microsoft, социальная. Дело в том, что разработчики не вносят в ядро таких оптимизаций, которые мы видим в мире Linux. В компании Microsoft никто не будет хвалить программиста, если он оптимизировал какой-то процесс на 5%, если это не входит в сферу его основных обязанностей. Такая оптимизация никому не интересна. Только в случае какого-то очень существенного прогресса работу программиста могут заметить в соседних командах разработки, что положительно отразится на его карьере. Но это скорее исключение, чем правило. Нет никакого стимула принимать изменения из-за пределов своей команды разработки.

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.