Предлагаем Вашему вниманию интервью с Сергеем Семеновым aka Serge (на Хабре ion2), одним из самых продуктивных разработчиков в проекте KolibriOS.
Интервью было проведено Сергеем Кузьминым aka Wildwest (на Хабре W__W)
У тебя есть хобби?
Когда-то я клеилтанчики корабли и самолёты. Теперь хобби стало программирование железа, чтение документации и изучение чужого кода.
Как и когда ты заинтересовался компьютерами и программированием? Какие книги были полезными для тебя?
Сперва были программируемые калькуляторы и первые статьи в журнале «Наука и жизнь». Это был 1985 год. До этого домашний компьютер казался мне таким же нереальным, как полёт на Луну. Потом появилась Искра 1080, на которой я изучал ассемблер 8080.
Из книг «Просто и ясно о Borland C++», отличная «освой самостоятельно Программирование в Windows за 21 день» Чарльза Калверта, наши «Язык программирования Си для персонального компьютера» и «Использование Turbo Assembler при разработке программ». Конечно «Программирование на аппаратном уровне» Кулакова и ещё два десятка других книг, Страуструп в их числе. Но почётное место на книжной полке занимают три тома «IA-32 Intel Architecture Software Developer's Manual» и руководство по оптимизации. Было время, когда Интел рассылал эти кирпичи по всему свету.
Какие ОС пробовал? Какие твоя домашняя, рабочая и самая любимая ОС?
DOS 3.0, 4.0, 5.0 и почти все Windows: 3.1, 95, 95OSR2, 98, NT4.0, XP, Win7.
Сейчас стоит 8.1 Она меня вполне устраивает, но перегружаться в Колибри из предыдущих было удобней. Ещё пользовался разными Linux и остановился на Debian Jessie и KDE desktop.
Какие языки программирования ты знаешь и почему учил их? Какие из них ты любишь больше других и почему?
На курсах в универе знакомили с PL/M, в школе мучили ершолом. В институте был обязательный fortran, на работе Clarion 2.0. Некоторое время пользовался Borland Pascal 7.0, но потом надоел этот жуткий синтаксис и перешёл на Си. С тех пор прошло 20 лет.
Что можешь сказать относительно своих проектов (предыдущих и текущих), которые не связаны с KolibriOS?
Сейчас таких не осталось.
Как и когда ты обнаружил KolibriOS? Сразу ли начал разрабатывать для неё? Почему ты программируешь для неё?
В 2001 году в Компьютерре была маленькая заметка о MenuetOS. Наверное там писали о какой-то другой Menuet, потому что свежескачанная 0.38 жутко тормозила и выглядела страшновато. Время от времени я проверял новые версии, пока в 2006 не наткнулся на Колибри. Новая системка была намного симпатичнее на вид и работала шустрее. Потом я попал на форум и влез в дискуссию об обработке IRQ. Кто-то опять был неправ. Так и засосало. Мне всегда было интересно «играться» с железом. Колибри удобна тем, что в ней нет сложных HAL прослоек между ядром и железом. Всё очень просто, наглядно и ядро компилируется и загружается мгновенно. Это немаловажно, когда делаешь это по сотне раз.
Чем занимался и занимаешься в проекте KolibriOS? Опиши текущее состояние своих проектов и их историю.
Первым проектом была звуковая подсистема. В Колибри был плеер ac97wav Ивана Поддубного, работавший напрямую с контроллером и кодеком. Проблема была в том, что программа не могла обрабатывать прерывания от контроллера и звук шёл со щелчками, во-вторых это был монопольный доступ к железу. Требовалось сделать загружаемый драйвер и системный микшер, чтобы несколько программ могли одновременно выводить звук. С драйвером контроллера для AC97 не было особых проблем, хотя по глупости спалил наушники, но тестировать код приходилось в unreal mode DOS, потому что в ядре была нулевая поддержка загружаемых драйверов. Нельзя было выделить виртуальную память в ядре, замапить физическую страницу на требуемый адрес, установить обработчик IRQ и т.п. Даже не было внутренней функции для загрузки файла. Приходилось делать это через вызов ядра 0x40. В результате пришлось написать управление страничной и виртуальной памятью, загрузчик драйверов, переделать обработку IRQ, прежде чем в Колибри появился звук.
Второй большой работой, все ещё незавершённой, было преодоление наследства «тяжелого финского прошлого». Во-первых, в коде Менует не использовались символьные имена переменных. В ранних ревизиях Колибри приходилось продираться через
или
Во-вторых, «маленькое ассемблерное ядро» жрало память в совершенно диких количествах. Для байтовой переменной было типичным выделение килобайта, для буфера десятков килобайт — адреса абсолютные, поэтому выравнивали на красивые круглые значения. Всё это было от бедности. Если ядро не умеет динамически выделять память, остаётся резервировать статически и с запасом. Постепенно все абсолютные адреса были заменены символьными метками а аппетит ядра ужат примерно в три раза.
Ещё было множество мелких и не очень изменений в ядре и бесконечная эпопея с видеокартами. Сперва был ассемблерный драйвер для ATI R100-R500, включавший аппаратные курсоры. Потом AMD представило radeonhd и в Колибри появилась возможность менять видеорежим. Через несколько месяцев ядро Линукс вслед за Колибри :-) перешло на KMS и новый драйвер был опять портирован. В конце 11 года появился драйвер для i915, а через два года Mesa драйвер i965 и закрутились первые «железные» шестерёнки. Параллельно был портирован ffmpeg и сделан видеоплеер на его базе. + портированы несколько популярных библиотек: cairo, freetype, libpng, zlib, mesa. Последним проектом были binutils: ar as ld objcopy strip, всё что нужно для линковки непосредственно в Колибри.
Расскажи про бранчи ядра, разрабатываемые тобой.
kolibri-acpi правильнее назвать kolibri-next. Здесь тестируется код перед включением в основное ядро.
Kolibri-process — улучшалась поддержка многопоточных приложений. Изменения залиты в основное ядро, ветка удалена за ненадобностью.
kolibri_pe – историю и мотивы лучше почитать на форуме. Начальная часть работы была успешно завершена. Код ядра на Си и ассемблере линковался при помощи ld в PE DLL с фиксированным базовым адресом. Ядро загружалось GRUB, прыгало из защищённого в real mode, показывало наш любимый синий экран загрузки с выбором опций, включало графический режим и возвращалось в защищённый режим. Первый гвоздь в крышку проекта забила АМД. Появился драйвер redеonhd, на который я сразу переключился. Второй гвоздь был от CCP Games.
Результаты представлены на FTP-сервере проекта, в ночной сборке. Какой из этих проектов был самым трудным?
Портирование Doom. Уже была версия для Менуэт, так что работа казалась не слишком сложной, главной задачей было добавить звук. Но чёртова программа вылетала после загрузки и было совсем непонятно в чём дело. Пришлось неделю возиться с отладкой, прежде чем выяснилось, что id Software и Open Watcom по разному определяют sizeof(bool). Дальше всё пошло как по маслу.
Ты программировал для устройств разных фирм, читал документацию. Были ли сложные моменты, когда было ограничение со стороны железа или со стороны ОС?
В Колибри нет поддержки ACPI и диспетчера устройств. Это создаёт множество проблем. Например ядро до сих пор обрабатывает прерывания в режиме доисторического 8259A, а BIOS часто назначает разным PCI устройствам общие линии IRQ. В теории такое разделение линий должно работать, но в реальной жизни это не так. Ядро умеет работать и в режиме APIC, но это требует некоторых подготовительных действий со стороны пользователя и, к сожалению, положительный результат не гарантирован.
Перечисление устройств на шине PCI даёт информацию об используемых ресурсах, но без ACPI она неполна. Иногда устройствам (i915 Gen3 gpu) требуется незанятый диапазон физических адресов, а у ядра недостаточно данных для его резервирования. А ещё есть древний SoundBlaster, способный работать только в первых 16Мб, и для него приходится статически резервировать память.
Драйверы для звуковых и видеокарт, портирование библиотек, видеоплеер… Что дальше?
В планах 3D драйверы для AMD Radeon и аппаратное декодирование видео в Fplay. К сожалению, на этом пути есть несколько препятствий. Fplay использует ffmpeg, а его разработчики не очень дружны с разработчиками VAAPI и libVA, наверное потому, что у последних есть свой gstreamer. С другой стороны у ffmpeg всё прекрасно с vdpau, так что на радеонах декодер заработает, как только будут готовы r600 и radeonsi для Galluim3D. Но они зависят от llvm, а портированная llvm вместо ожидаемого кода генерирует… Неизвестно точно, что и как генерирует llvm, потому что трассировка двадцатимегабайтного бинарника немного затруднительна без отладчика с поддержкой исходного кода.
Часто приходят новички и спрашивают про переписывание отдельных частей ОС, портирование на другие аппаратные платформы. Время от времени даже появляются форки разработчиков-одиночек, например от mike.dld, art_zh и т.п. Как ты к этому относишься?
Спокойно отношусь. Я сам запустил форк, а потом бросил.
Важна ли совместимость c аппаратными платформами или другими ОС для KolibriOS?
Колибри ассемблерная система для x86. Вряд ли есть смысл говорить о других аппаратных платформах.
Ты в основном пишешь и портируешь программы на С++. Какие инструменты ты используешь в разработке ?
У нас есть тулчейн на основе gcc-4.8.2 и binutils-2.24 в версиях для Windows и Linux и небольшой набор необходимых библиотек, в том числе libstdc++.
Часто ли приходится править стандартные библиотеки компилятора, добавляя недостающие функции? Насколько полно поддерживается POSIX?
С/С++ программы используют newlib в качестве стандартной библиотеки. Всё начиналось с видеоплеера на базе ffpmeg. В первой версии было минимально необходимое количество функций. С каждым новым проектом я добавляю требуемые функции в newlib. Это конечно неправильно, но портирование стандартной библиотеки довольно нудное занятие. В menuetlibc POSIX поддерживается в большем объёме. В целом все трудности с POSIX преодолимы, требуется немного упорства и терпения.
Можешь дать какой-нибудь совет стремящимся стать программистами? Какие языки надо попробовать? Что посоветуешь разработчикам новых ОС? Как начать? Какие учебники читать?
Раньше я бы посоветовал изучить ассемблер для целевой платформы, чтобы понимать во что в итоге превратится твой код. А теперь всё кроссплатформенное, интерпретируемое и неизвестно на чём оно будет исполняться. Но для разработчиков ОС есть несколько советов:
Ну а теперь хочется спросить вас, наши читатели, на какие темы, связанные с КолибриОС, вы бы хотели увидеть статьи?
Интервью было проведено Сергеем Кузьминым aka Wildwest (на Хабре W__W)
У тебя есть хобби?
Когда-то я клеил
Как и когда ты заинтересовался компьютерами и программированием? Какие книги были полезными для тебя?
Сперва были программируемые калькуляторы и первые статьи в журнале «Наука и жизнь». Это был 1985 год. До этого домашний компьютер казался мне таким же нереальным, как полёт на Луну. Потом появилась Искра 1080, на которой я изучал ассемблер 8080.
Из книг «Просто и ясно о Borland C++», отличная «освой самостоятельно Программирование в Windows за 21 день» Чарльза Калверта, наши «Язык программирования Си для персонального компьютера» и «Использование Turbo Assembler при разработке программ». Конечно «Программирование на аппаратном уровне» Кулакова и ещё два десятка других книг, Страуструп в их числе. Но почётное место на книжной полке занимают три тома «IA-32 Intel Architecture Software Developer's Manual» и руководство по оптимизации. Было время, когда Интел рассылал эти кирпичи по всему свету.
Скрытый текст
Тёплые ламповые мануалы до
и после обновления
и после обновления
Какие ОС пробовал? Какие твоя домашняя, рабочая и самая любимая ОС?
DOS 3.0, 4.0, 5.0 и почти все Windows: 3.1, 95, 95OSR2, 98, NT4.0, XP, Win7.
Сейчас стоит 8.1 Она меня вполне устраивает, но перегружаться в Колибри из предыдущих было удобней. Ещё пользовался разными Linux и остановился на Debian Jessie и KDE desktop.
Какие языки программирования ты знаешь и почему учил их? Какие из них ты любишь больше других и почему?
На курсах в универе знакомили с PL/M, в школе мучили ершолом. В институте был обязательный fortran, на работе Clarion 2.0. Некоторое время пользовался Borland Pascal 7.0, но потом надоел этот жуткий синтаксис и перешёл на Си. С тех пор прошло 20 лет.
Что можешь сказать относительно своих проектов (предыдущих и текущих), которые не связаны с KolibriOS?
Сейчас таких не осталось.
Как и когда ты обнаружил KolibriOS? Сразу ли начал разрабатывать для неё? Почему ты программируешь для неё?
В 2001 году в Компьютерре была маленькая заметка о MenuetOS. Наверное там писали о какой-то другой Menuet, потому что свежескачанная 0.38 жутко тормозила и выглядела страшновато. Время от времени я проверял новые версии, пока в 2006 не наткнулся на Колибри. Новая системка была намного симпатичнее на вид и работала шустрее. Потом я попал на форум и влез в дискуссию об обработке IRQ. Кто-то опять был неправ. Так и засосало. Мне всегда было интересно «играться» с железом. Колибри удобна тем, что в ней нет сложных HAL прослоек между ядром и железом. Всё очень просто, наглядно и ядро компилируется и загружается мгновенно. Это немаловажно, когда делаешь это по сотне раз.
Чем занимался и занимаешься в проекте KolibriOS? Опиши текущее состояние своих проектов и их историю.
Первым проектом была звуковая подсистема. В Колибри был плеер ac97wav Ивана Поддубного, работавший напрямую с контроллером и кодеком. Проблема была в том, что программа не могла обрабатывать прерывания от контроллера и звук шёл со щелчками, во-вторых это был монопольный доступ к железу. Требовалось сделать загружаемый драйвер и системный микшер, чтобы несколько программ могли одновременно выводить звук. С драйвером контроллера для AC97 не было особых проблем, хотя по глупости спалил наушники, но тестировать код приходилось в unreal mode DOS, потому что в ядре была нулевая поддержка загружаемых драйверов. Нельзя было выделить виртуальную память в ядре, замапить физическую страницу на требуемый адрес, установить обработчик IRQ и т.п. Даже не было внутренней функции для загрузки файла. Приходилось делать это через вызов ядра 0x40. В результате пришлось написать управление страничной и виртуальной памятью, загрузчик драйверов, переделать обработку IRQ, прежде чем в Колибри появился звук.
Второй большой работой, все ещё незавершённой, было преодоление наследства «тяжелого финского прошлого». Во-первых, в коде Менует не использовались символьные имена переменных. В ранних ревизиях Колибри приходилось продираться через
mov eax,[0xFE00]
shr eax,1
mov [0xFB0A],ax
mov eax,[0xFE04]
shr eax,1
mov [0xFB0C],ax
или
mov edi, [0x3004]; the last process (number)
movzx esi, word [0xC400 + edi * 2]
shl esi, 5
add esi, window_data
Во-вторых, «маленькое ассемблерное ядро» жрало память в совершенно диких количествах. Для байтовой переменной было типичным выделение килобайта, для буфера десятков килобайт — адреса абсолютные, поэтому выравнивали на красивые круглые значения. Всё это было от бедности. Если ядро не умеет динамически выделять память, остаётся резервировать статически и с запасом. Постепенно все абсолютные адреса были заменены символьными метками а аппетит ядра ужат примерно в три раза.
Ещё было множество мелких и не очень изменений в ядре и бесконечная эпопея с видеокартами. Сперва был ассемблерный драйвер для ATI R100-R500, включавший аппаратные курсоры. Потом AMD представило radeonhd и в Колибри появилась возможность менять видеорежим. Через несколько месяцев ядро Линукс вслед за Колибри :-) перешло на KMS и новый драйвер был опять портирован. В конце 11 года появился драйвер для i915, а через два года Mesa драйвер i965 и закрутились первые «железные» шестерёнки. Параллельно был портирован ffmpeg и сделан видеоплеер на его базе. + портированы несколько популярных библиотек: cairo, freetype, libpng, zlib, mesa. Последним проектом были binutils: ar as ld objcopy strip, всё что нужно для линковки непосредственно в Колибри.
Скрытый текст
Расскажи про бранчи ядра, разрабатываемые тобой.
kolibri-acpi правильнее назвать kolibri-next. Здесь тестируется код перед включением в основное ядро.
Kolibri-process — улучшалась поддержка многопоточных приложений. Изменения залиты в основное ядро, ветка удалена за ненадобностью.
kolibri_pe – историю и мотивы лучше почитать на форуме. Начальная часть работы была успешно завершена. Код ядра на Си и ассемблере линковался при помощи ld в PE DLL с фиксированным базовым адресом. Ядро загружалось GRUB, прыгало из защищённого в real mode, показывало наш любимый синий экран загрузки с выбором опций, включало графический режим и возвращалось в защищённый режим. Первый гвоздь в крышку проекта забила АМД. Появился драйвер redеonhd, на который я сразу переключился. Второй гвоздь был от CCP Games.
Результаты представлены на FTP-сервере проекта, в ночной сборке. Какой из этих проектов был самым трудным?
Портирование Doom. Уже была версия для Менуэт, так что работа казалась не слишком сложной, главной задачей было добавить звук. Но чёртова программа вылетала после загрузки и было совсем непонятно в чём дело. Пришлось неделю возиться с отладкой, прежде чем выяснилось, что id Software и Open Watcom по разному определяют sizeof(bool). Дальше всё пошло как по маслу.
Скрытый текст
Ты программировал для устройств разных фирм, читал документацию. Были ли сложные моменты, когда было ограничение со стороны железа или со стороны ОС?
В Колибри нет поддержки ACPI и диспетчера устройств. Это создаёт множество проблем. Например ядро до сих пор обрабатывает прерывания в режиме доисторического 8259A, а BIOS часто назначает разным PCI устройствам общие линии IRQ. В теории такое разделение линий должно работать, но в реальной жизни это не так. Ядро умеет работать и в режиме APIC, но это требует некоторых подготовительных действий со стороны пользователя и, к сожалению, положительный результат не гарантирован.
Перечисление устройств на шине PCI даёт информацию об используемых ресурсах, но без ACPI она неполна. Иногда устройствам (i915 Gen3 gpu) требуется незанятый диапазон физических адресов, а у ядра недостаточно данных для его резервирования. А ещё есть древний SoundBlaster, способный работать только в первых 16Мб, и для него приходится статически резервировать память.
Драйверы для звуковых и видеокарт, портирование библиотек, видеоплеер… Что дальше?
В планах 3D драйверы для AMD Radeon и аппаратное декодирование видео в Fplay. К сожалению, на этом пути есть несколько препятствий. Fplay использует ffmpeg, а его разработчики не очень дружны с разработчиками VAAPI и libVA, наверное потому, что у последних есть свой gstreamer. С другой стороны у ffmpeg всё прекрасно с vdpau, так что на радеонах декодер заработает, как только будут готовы r600 и radeonsi для Galluim3D. Но они зависят от llvm, а портированная llvm вместо ожидаемого кода генерирует… Неизвестно точно, что и как генерирует llvm, потому что трассировка двадцатимегабайтного бинарника немного затруднительна без отладчика с поддержкой исходного кода.
Часто приходят новички и спрашивают про переписывание отдельных частей ОС, портирование на другие аппаратные платформы. Время от времени даже появляются форки разработчиков-одиночек, например от mike.dld, art_zh и т.п. Как ты к этому относишься?
Спокойно отношусь. Я сам запустил форк, а потом бросил.
Важна ли совместимость c аппаратными платформами или другими ОС для KolibriOS?
Колибри ассемблерная система для x86. Вряд ли есть смысл говорить о других аппаратных платформах.
Ты в основном пишешь и портируешь программы на С++. Какие инструменты ты используешь в разработке ?
У нас есть тулчейн на основе gcc-4.8.2 и binutils-2.24 в версиях для Windows и Linux и небольшой набор необходимых библиотек, в том числе libstdc++.
Часто ли приходится править стандартные библиотеки компилятора, добавляя недостающие функции? Насколько полно поддерживается POSIX?
С/С++ программы используют newlib в качестве стандартной библиотеки. Всё начиналось с видеоплеера на базе ffpmeg. В первой версии было минимально необходимое количество функций. С каждым новым проектом я добавляю требуемые функции в newlib. Это конечно неправильно, но портирование стандартной библиотеки довольно нудное занятие. В menuetlibc POSIX поддерживается в большем объёме. В целом все трудности с POSIX преодолимы, требуется немного упорства и терпения.
Можешь дать какой-нибудь совет стремящимся стать программистами? Какие языки надо попробовать? Что посоветуешь разработчикам новых ОС? Как начать? Какие учебники читать?
Раньше я бы посоветовал изучить ассемблер для целевой платформы, чтобы понимать во что в итоге превратится твой код. А теперь всё кроссплатформенное, интерпретируемое и неизвестно на чём оно будет исполняться. Но для разработчиков ОС есть несколько советов:
- Присоединиться к существующему проекту или найти единомышленников. Три головы в четыре раза лучше одной.
- Не стоит начинать разработку с микроядра, особенно в одиночку. Вам будет сложнее разрабатывать драйверы и приложения.
- Когда будете придумывать свой «уникальный, не имеющий аналогов API» вспомните о POSIX. Рано или поздно вам понадобится совместимость.
Ну а теперь хочется спросить вас, наши читатели, на какие темы, связанные с КолибриОС, вы бы хотели увидеть статьи?