• Разработка драйвера PCI устройства под Linux


      В данной статье я рассматриваю процесс написания простого драйвера PCI устройства под OC Linux. Будет кратко изучено устройство программной модели PCI, написание собственно драйвера, тестовой пользовательской программы и запуск всей этой системы.

      В качестве подопытного выступит интерфейс датчиков перемещения ЛИР940/941. Это устройство, отечественного производства, обеспечивает подключение до 4 энкодеров с помощью последовательного протокола SSI поверх физического интерфейса RS-422.
      Читать дальше →
    • Что действительно случилось с Vista: инсайдерская ретроспектива

      • Перевод

      Традиционно группа разработчиков Windows подписывает постер (в данном случае изображение DVD) с выпуском новой версии Windows. Ко времени окончания вечеринки по поводу релиза на нём будут сотни или тысячи подписей

      «Опыт — это то, что ты получаешь только после того, как он тебе понадобится» — Стивен Райт

      Мне понравился содержательный блог Терри Кроули («Что действительно случилось с Vista»). Терри работал в группе Office и проделал фантастическую работу, описывая сложные козни вокруг Windows Vista и связаного, но заброшенного проекта Longhorn — с точки зрения внешнего наблюдателя.

      Он верно подметил многие из проблем, которые преследовали проект, и я не хочу повторять о них снова. Я только подумал, что будет честно изложить инсайдерский взгляд на те же события. Не рассчитываю на такое же красноречивое или исчерпывающее изложение, как у Терри, но надеюсь пролить некоторый свет на то, что пошло не так. Прошло десять лет с момента выхода первой версии Windows Vista, но эти уроки сейчас кажутся актуальными как никогда.
      Читать дальше →
    • Миром всё ещё управляет язык С

      • Перевод
      Многие из проектов на языке С, существующих сегодня, начинали разрабатываться ещё десятилетия назад. Операционная система UNIX стартовала 1969 году (и писалась на ассемблере), но уже в 1972 была переписана на С. Точнее, это язык С был создан для того, чтобы появилось что-то, на что было бы удобно переписать с ассемблера ядро UNIX и получить чуть более высокоуровневый код, менее зависимый от архитектуры и позволяющий выполнять больше полезной работы на каждую строчку написанного кода.

      Разработка базы данных Oracle началась в 1977 году (тоже на ассемблере) и тоже была переписана на С в 1983 году. К тому времени это был уже один из самых популярных языков в мире.

      В 1985 году вышла Windows 1.0. Хотя код операционной системы Windows не является открытым, общеизвестно, что ядро в основном написано на С с небольшими вставками ассемблера. Разработка Linux началась в 1991 году и началась сразу на С. В следующем году она была опубликована под лицензией GPL и использована как часть GNU Operating System, которая и сама начиналась как проект на С и Lisp, так что многие компоненты были написаны на С.

      Но проекты на С — это не только то, что стартовало десятилетия назад, когда выбор языков, скажем прямо, был достаточно ограничен. Много С-кода пишется и сейчас, на нём начинаются и новые проекты. Для этого есть причины.

      Как именно язык С управляет миром?

      Читать дальше →
    • Эволюция системных вызовов архитектуры x86

        Про системные вызовы уже много было сказано, например здесь или здесь. Наверняка вам уже известно, что системный вызов — это способ вызова функции ядра ОС. Мне же захотелось копнуть глубже и узнать, что особенного в этом системном вызове, какие существуют реализации и какова их производительность на примере архитектуры x86-64. Если вам также интересны ответы на данные вопросы, добро пожаловать под кат.

        Читать дальше →
      • Выравнивание инструкций кода

        • Перевод
        Насколько трудно может быть измерить производительность простой функции, вроде вот этой?

        // func.cpp
        void benchmark_func(int* a)
        {
        	for (int i = 0; i < 32; ++i)
        		a[i] += 1;
        }

        Ну, давайте просто завернём её в какой-нибудь микробенчмарк, вызовем её много-много раз (для усреднения результатов) и посмотрим, что получится, да? Ну ладно, мы можем ещё посмотреть на сгенерированные инструкции просто чтобы убедиться, что компилятор чего-то там не «наоптимизировал». Мы можем также провести несколько разных тестов, чтобы убедиться, что именно цикл является узким местом. Ну и всё. Мы понимаем, что мы измеряем, да?

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

        // func.cpp
        void foo(int* a)
        {
        	for (int i = 0; i < 32; ++i)
        		a[i] += 1;
        }
        
        void benchmark_func(int* a)
        {
        	for (int i = 0; i < 32; ++i)
        		a[i] += 1;
        }

        И вот однажды ваш менеджер приходит к вам и показывает претензию от пользователя вашей библиотеки, которая заключается в том, что она не работает настолько быстро, как вы обещали. Но постойте, мы ведь хорошо измерили производительность и обещали ровно то, что получили по результатам тестов. Что же пошло не так?
        Читать дальше →
      • Время отклика компьютеров: 1977−2017

        • Перевод
        У меня гнетущее чувство, что современные компьютеры по ощущениям медленнее, чем те компьютеры, которые я использовал в детстве. Я не доверяю такого рода ощущениям, потому что человеческое восприятие доказало свою ненадёжность в эмпирических исследованиях, так что я взял высокоскоростную камеру и измерил время отклика устройств, которые попали ко мне за последние несколько месяцев. Вот результаты:

        Компьютер Отклик
        (мс)
        Год Тактовая
        частота
        Кол-во
        транзисторов
        Apple 2e 30 1983 1 МГц 3,5 тыс.
        TI 99/4A 40 1981 3 МГц 8 тыс.
        Haswell-E 165 Гц 50 2014 3,5 ГГц 2 млрд
        Commodore Pet 4016 60 1977 1 МГц 3,5 тыс.
        SGI Indy 60 1993 0,1 ГГц 1,2 млн
        Haswell-E 120 Гц 60 2014 3,5 ГГц 2 млрд
        ThinkPad 13 ChromeOS 70 2017 2,3 ГГц 1 млрд
        iMac G4 OS 9 70 2002 0,8 ГГц 11 млн
        Haswell-E 60 Гц 80 2014 3,5 ГГц 2 млрд
        Mac Color Classic 90 1993 16 МГц 273 тыс.
        PowerSpec G405 Linux 60 Гц 90 2017 4,2 ГГц 2 млрд
        MacBook Pro 2014 100 2014 2,6 ГГц 700 млн
        ThinkPad 13 Linux chroot 100 2017 2,3 ГГц 1 млрд
        Lenovo X1 Carbon 4G Linux 110 2016 2,6 ГГц 1 млрд
        iMac G4 OS X 120 2002 0,8 ГГц 11 млн
        Haswell-E 24 Гц 140 2014 3,5 ГГц 2 млрд
        Lenovo X1 Carbon 4G Win 150 2016 2,6 ГГц 1 млрд
        Next Cube 150 1988 25 МГц 1,2 млн
        PowerSpec G405 Linux 170 2017 4,2 ГГц 2 млрд
        Пакет вокруг света 190
        PowerSpec G405 Win 200 2017 4,2 ГГц 2 млрд
        Symbolics 3620 300 1986 5 МГц 390 тыс.
        Читать дальше →
      • AdBlock похитил этот баннер, но баннеры не зубы — отрастут

        Подробнее
        Реклама
      • Небольшая история о команде `yes` в Unix

        • Перевод
        Какую вы знаете самую простую команду Unix? Есть echo, которая печатает строку в stdout, и есть true, которая ничего не делает, а только завершается с нулевым кодом.

        Среди множества простых Unix-команд спряталась команда yes. Если запустить её без аргументов, то вы получите бесконечный поток символов "y", каждый с новой строки:

        y
        y
        y
        y
        (...ну вы поняли мысль)

        Хотя на первый взгляд команда кажется бессмысленной, но иногда она бывает полезной:

        yes | sh boring_installation.sh

        Когда-нибудь устанавливали программу, которая требует ввести "y" и нажать Enter для установки? Команда yes приходит на помощь! Она аккуратно выполнит эту задачу, так что можете не отвлекаться от просмотра Pootie Tang.
        Читать дальше →
      • t1ha = Fast Positive Hash

        Чуть менее, чем самая быстрая, переносимая, 64-битная хеш-функция, с достойным качеством.
        Да, вжух и в дамки, примерно так. Читаем дальше?

        Читать дальше →
      • Почему GitHub не может хостить ядро Linux

        • Перевод
        Некоторое время назад на отличной конференции maintainerati я пообщался с несколькими друзьями-мейнтейнерами о масштабировании по-настоящему больших проектов open source и о том, как GitHub подталкивает проекты к определённому способу масштабирования. У ядра Linux абсолютно иная модель, которую мейнтейнеры-пользователи GitHub не понимают. Думаю, стоит объяснить, почему и как она работает и чем отличается.

        Ещё одной причиной для написания этого текста стала дискуссия на HN по поводу моего выступления «Мейнтейнеры не масштабируются», где самый популярный комментарий сводился к вопросу «Почему эти динозавры не используют современные средства разработки?». Несколько известных разработчиков ядра энергично защищали списки рассылки и предложение патчей через механизм, похожий на пулл-реквесты GitHub, Но по крайней мере несколько разработчиков графической подсистемы хотели бы использовать более современный инструментарий, который гораздо легче автоматизировать скриптами. Проблема в том, что GitHub не поддерживает тот способ, которым ядро Linux масштабируется на огромное число контрибуторов, и поэтому мы просто не можем перейти на него, даже для нескольких подсистем. И дело не в хостинге данных на Git, эта часть явно в порядке, а дело в том, как на GitHub работают пулл-реквесты, обсуждение багов и форки.
        Читать дальше →
      Самое читаемое