Привет хаброчитателям!

В предыдущей части мы рассмотрели базовые структуры, а также написали инициализацию и удаление устройства.

В данной статье мы добавим в наш драйвер функции открытия scull_open, чтения/записи scull_read/scull_write и получим первый рабочий драйвер устройства.



Хочу выразить благодарность всем пользователям, которые прочитали, лайкнули и прокомментировали мою предыдущую статью. Отдельное спасибо за уточнения Kolyuchkin и dlinyj.



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

Сразу к делу!

Вдохновение на написание данной статьи было получено после прочтения похожей публикации для архитектуры x86 [1].

Данный материал поможет тем, кто хочет понять, как устроены программы изнутри, что происходит до входа в main и для чего всё это делается. Также я покажу как можно использовать некоторые особенности библиотеки glibc. И в конце, как и в оригинальной статье [1] будет визуально представлен пройденный путь. В большинстве своём статья представляет собой разбор библиотеки glibc.

Итак, начнём наш поход. Будем использовать Linux x86-64, а в качестве инструмента отладки — lldb. Также иногда будем дизассемблировать программу при помощи objdump.

Исходным текстом будет обычный Hello, world (hello.cpp):

#include <iostream>
int main()
{
        std::cout << "Hello, world!" << std::endl;
}

Привет, Хабр! Неделю назад я рассказывал вам о новой возможности, которая доступна в предварительных выпусках Docker и Windows Server/Windows 10 — запуск Linux контейнеров c Hyper-V изоляцией, аналогично Windows контейнерам с Hyper-V изоляцией. В этом пошаговом руководстве речь пойдёт про аналогичный запуск контейнеров с Ubuntu в этом окружении.

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

В последнее время на программистских форумах развернулись неслабые дискуссии (для примера см. здесь, здесь и здесь, и эта сегодняшняя) об Electron и его влиянии на сферу разработки десктопных приложений.

Если вы не знаете Electron, то это по сути веб-браузер (Chromium) в котором работает только ваше веб-приложение… словно настоящая десктопная программа (нет, это не шутка)… это даёт возможность использовать веб-стек и разрабатывать кросс-платформенные десктопные приложения.

Самые новые, хипстерские десктопные приложения в наше время сделаны на Electron, в том числе Slack, VS Code, Atom и GitHub Desktop. Необычайный успех.

Мы писали десктопные программы десятилетиями. С другой стороны, веб только начал развиваться менее 20 лет назад, и на протяжении почти всего этого времени он служил только для доставки документов и анимированных «гифок». Никто не использовал его для создания полноценных приложений, даже самых простых!

Скоро выйдет новое большое обновление для операционной системы Windows Server, в начале сентября в блоге TechNet вышел небольшой пост об этом, и некоторые ее новые функции порадуют пользователей Docker. Одна из главных новостей заключается в том, что
благодаря технологии Hyper-V, Docker теперь сможет выполнять Linux-контейнеры в Windows, аналогично Hyper-V Windows контейнерам.

В современном мире, когда светлое будущее прочат микросервисам, кажется странным заниматься технологиями, которые помогают обновлять код без перезагрузки. Ведь микросервисы и контейнеры куда проще «убить» и создать заново. Тем не менее, мы продолжаем работу над системой живой миграции CRIU, и нам в этом активно помогают ребята из IBM. Почему? Попробуем объяснить.

Бытует мнение, что бесконечно можно смотреть на огонь, воду и то, как другие работают, но есть и ещё кое-что! Мы уверены, что можно бесконечно говорить с Сашей goldshtn Гольдштейном о перформансе. Мы уже брали у Саши интервью перед JPoint 2017, но тогда разговор касался конкретно BPF, которому был посвящен доклад Саши.

На этот раз мы решили копнуть глубже и узнать фундаментальные проблемы мониторинга производительности и варианты их решения.

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

Загрузка ARM в четырех прямоугольниках — под катом.

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

Мотивация

Проблема сборки и запуска проекта на разных машинах преследовала меня всегда. Для того, чтобы реалистично смоделировать работу разрабатываемого сайта на локальной машине нужно установить Web-сервер, Application-сервер, возможно, к ним присоединится какой-нибудь ещё промежуточный сервер, установить базу данных, настроить базу данных. Для того, чтобы установить тестовый сайт на тестовый сервер, нужно проделать такую же работу. И позже тоже самое с рабочим сервером.

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

Название статьи подсказала тема на одном из форумов. Несмотря на то, что с момента возникновения вопроса прошло шесть лет, в этом направлении мало что изменилось. А поскольку в последнее время у меня на слуху постоянно был OpenVPN, то было решено исправить данную ситуацию. Так родилась графическая утилита VpnGUI для создания, редактирования, запуска и контроля выполнения утилиты openvpn.

После запуска утилиты VpnGUI в трее появится иконка (квадрат разбитый на четыре сине-красных квадратика) утилиты:

Nuklear+ (читается как "Nuklear cross", значит "кроссплатформенный Nuklear") — это надстройка над GUI библиотекой Nuklear, которая позволяет абстрагироваться от драйвера вывода и взаимодействия с операционной системой. Нужно написать один простой код, а он потом уже сможет скомпилироваться под все поддерживаемые платформы.

Я уже писал на хабре статью "Nuklear — идеальный GUI для микро-проектов?". Тогда задача была простой — сделать маленькую кроссплатформенную утилиту с GUI, которая будет примерно одинаково выглядеть в Windows и Linux. Но с тех самых пор меня не отпускал вопрос, а можно ли на Nuklear сделать что-то более-менее сложное? Можно ли целиком на нём сделать какой-нибудь реальный проект, которым будут пользоваться?

Здравствуйте, дорогие хабрачитатели.

Цель данной статьи — показать принцип реализации драйверов устройств в системе Linux, на примере простого символьного драйвера.

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

Это моя первая статья, пожалуйста не судите строго!

P.S

Получилось слишком много букв, поэтому я принял решение разделить статью на три части:

Часть 1 — Введение, инициализация и очистка модуля ядра.
Часть 2 — Функции open, read, write и trim.
Часть 3 — Пишем Makefile и тестируем устройство.

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

Итак, начнем.

В этом посте мы решили рассказать о доменной аутентификации в Linux, с использованием смарт-карт и USB-токенов JaCarta PKI в качестве второго фактора аутентификации. Если о локальной аутентификации через PAM-модуль информации существует довольно много, то вопрос доменной инфраструктуры и аутентификация по Kerberos-билетам в Linux рассмотрен слабо, особенно на русском языке. В качестве операционной системы возьмем Astra Linux и на примере Astra Linux Directory (ALD) это и покажем.

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

Помимо атомарных операций KMS для пользователей рабочей станции Linux недавно завезли еще одно полезное новшество — планировщик подсистемы ввода и вывода BFQ (Budget Fair Queue). Он является усовершенствованием дефолтного CFQ (Completely Fair Queue), дебютировал аж 9 лет назад, но только в версии 4.12 попал в основную ветку.

Прежде чем поговорить о принципах работы планировщика ознакомьтесь с демо-роликом разработчика Paolo Valente, это добавит вам мотивации продолжить. На снимке экрана показан замер старта проигрывателя с 10 фоновыми задачами читать файл с диска для двух планировщиков: CFQ и BFQ. Угадайте, который из них так и не стартовал при такой нагрузке?

В новом ядре linux-4.4 переписали механизм работы с deviceTree. Теперь они больше не компилируются вместе с ядром, а поставляются отдельным репозиторием. В прошлый раз, когда я пытался завести китайский 4х дюймовый дисплей WaveShare, никаких адекватных мануалов не было. Максимум, что я смог найти — это исходники модуля для старого ядра (linux-3.8.13). Провозившись неделю я всё-таки собрал своё ядро, с которым не расстаюсь.

Но время меняется, уже давно все перешли на Debian 8.7, но мануалов как подключить дисплей BB-VIEW на новом ядре я так и не нашёл.

Леность ли моя тому причиной или болезненная неприязнь к комбайнам, но у меня как-то не сложились отношения с большими толстыми довольными IDE. Довольствуюсь простым ламповым Geany и несколькими самописными скриптами, количество коих растёт по мере необходимости.

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

О некоторых таких скриптах решил попробовать писать сюда. Может, кому пригодятся (да и заточить под себя какой-нибудь из них всегда можно). Если нет — ругайтесь в комментариях, учту. Итак.

Проблемы legacy-кода знакомы подавляющему большинству разработчиков программного обеспечения. Процесс превращения кода в legacy неизбежен, ведь прогресс в программировании не стоит на месте. Проекты либо «умирают» навсегда, либо требуют постоянной поддержки и написания новых функций. Таким образом, в любом проекте на любом языке программирования legacy-код возникает и доставляет разные неудобства при дальнейшей разработке. На примере PVS-Studio, в этой статье я расскажу, как сразу начать использовать статический анализатор кода в своём проекте.

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

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

С 4 по 8 августа в Нидерландах прошел крупный хакерский фестиваль SHA2017. Несмотря на интенсивную подготовку к своему выступлению (и сильное волнение перед ним), я посетил много интересных докладов. В этой заметке перечислю те из них, которые мне особенно понравились, и поделюсь впечатлениями.