Linux include version h

Установка Linux-2.4.19

Установка заголовочных файлов ядра

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

Скопируем заголовки ядра, выполнив следующие команды:

Пояснения команд

ln -s /static/bin/pwd /bin/pwd: В исходных кодах ядра путь к программе pwd прописан как /bin/pwd, поэтому создадим временную символическую ссылку, а в конце удалим ее.

make mrproper: Выполнение данной команды обеспечивает чистое дерево исходников ядра. Команда разработчиков ядра рекомендует выполнять эту команду перед каждой компиляцией ядра, даже если вы только что распаковали исходные коды из tar-архива.

make include/linux/version.h и make symlinks: Создадим файл include/linux/version.h file и символическую ссылку include/asm для конкретной платформы.

mkdir /usr/include/asm , cp include/asm/* /usr/include/asm и cp -R include/asm-generic /usr/include: Эти команды копируют заголовочные файлы ядра ассемблера для конкретной платформы в /usr/include/asm и /usr/include/asm-generic.

cp -R include/linux /usr/include: Эта команда копирует кросс-платформенные файлы заголовков в /usr/include.

touch /usr/include/linux/autoconf.h: Создаем пустой файл autoconf.h. Так как на данном этапе мы не конфигурируем ядро, необходимо вручную создать этот файл для некоторых заголовочных файлов ядра, использующих его, чтобы избежать ошибок при компиляции.

Почему мы копируем заголовки ядра, а не создаем для них символические ссылки?

Раньше было принято создавать символические ссылки директорий /usr/include/ на /usr/src/linux/include/ . Однако, это была плохая идея, как объясняет Линус Торвальдс в списке рассылки ядра Linux (Linux Kernel Mailing List, отрывок):

Наиболее важная часть сообщения Линуса заключается в том, что файлы заголовков должны быть именно теми, с которыми компилировался пакет glibc. Это те заголовки, которые следует использовать в будущем при компиляции других пакетов, т.к. именно они соответствуют файлам библиотек объектного кода. Копируя заголовки, мы удостоверяемся, что они останутся доступными, если позже мы решим обновить ядро.

Заметьте, что нет ничего страшного в том, что исходные коды ядра находятся в директории /usr/src/linux. Главное, чтобы у вас не было символических ссылок /usr/include/ .

Содержимое Linux

Последняя проверка: версия 2.4.18.

Файлы поддержки

Ядро Linuxи и его заголовочные файлы

Описания

Ядро Linux

Ядро — основа любой системы Linux. Когда компьютер включается и загружает Linux, первое, что загружается — ядро. Ядро инициализирует аппаратные компоненты системы: последовательные и параллельные порты, звуковые и сетевые карты, контроллеры IDE и SCSI и многое другое. In a nutshell the kernel makes the hardware available so that the software can run.

linux kernel headers

Это файлы, которые мы копируем в /usr/include/ в 5-й главе. Они должны соответствовать тем, с которым был скомпилирован glibc, и поэтому не должны быть заменены при смене ядра. Они имеют ключевое значение для компиляции многих программ.

Зависимости Linux

Последняя проверка: версия 2.4.17.

Bash: sh
Binutils: ar, as, ld, nm, objcopy
Fileutils: cp, ln, mkdir, mv, rm, touch
Findutils: find, xargs
Gcc: cc1, collect2, cpp0, gcc
Grep: grep
Gzip: gzip
Make: make
Gawk: awk
Modutils: depmod, genksyms
Net-tools: dnsdomainname, hostname
Sed: sed
Sh-utils: basename, date, expr, pwd, stty, uname, whoami, yes
Textutils: cat, md5sum, sort, tail

Источник

include/linux/version.h в 2.6.9

Пробую скомпилить 2.6.9 ядро. Весь софт удовлетворяет минимальным требованиям. Говорю make mrproper, make menuconfig После make выдает ошибку: /bin/sh: -c: line 1: unexpected EOF while looking for matching `»‘ /bin/sh: -c: line 2: syntax error: unexpected end of file make: *** [include/linux/version.h] Error 2

Файла include/linux/version.h у меня вообще нету. Насколько я понял из Makefile и документации он должен создаваться автоматически. В чем проблема?

Re: include/linux/version.h в 2.6.9

Вобщето ядра 2,6,х строятся в отдельной директории. поробуй создать директорию /home/имя пользователя/build потом из usr/src/linux make mrproper make O=/home/имя пользователя/build menuconfig Может дело вэтом.

Re: include/linux/version.h в 2.6.9

make include/linux/version.h сотворит этот файл 🙂

include/linux/version.h в 2.6.9

Так. Значит файлы я компилю в отдельный каталог (make O=/home/user/build). «make O=/home/user/build include/linux/version.h» выдает ту же самую ошибку, хотя /home/usr/build пустой, только что созданный, и в нем только make O=/home/user/build menuconfig отработало. «make include/linux/version.h» действительно создает этот файл (спасибо!) в дереве исходников. После этого «make» загибается опять с этой же ошибкой. Совсем уже ничего не пойму 🙁

include/linux/version.h в 2.6.9

Пробовал и так (в ридми все-таки написано, я читал :), и без O=, результат практически одинаковый.

Источник

Nvidia 173.14 и сырцы ядра

Почитал ридми по установке драйвера. Поставил, как там требовалось kernel-source, убедился в наличии ld При попытке запустить получаю ошибку

ЧС^W Что в высшей мере характерно, этих файлов действительно там нет. Зато есть другие:

Получаю другую ошибку:

Что я делаю не так? За три часа гугления нащупал только то, что вроде как сырцы нужно некоим образом сконфигурить. Типа в /usr/src должен лежать .config Ткните носом, что делать, куда рыть конкретнее? Примечательно то, что эта же карта (fx5200) прекрасно работала на другой машине, с этим же дистром

37-й уже пробовал. Только что проверил. Раньше карточка работала, похоже, на 173.14.05 Кочаю.

Бесполезно. «Сырцы не сконфигурированы и баста».

Вопрос снят, тема закрыта.

В общем, в заблуждение ввел талмуд nvidia. Там сказано, что для установки нужен либо kernel-sources, ЛИБО kernel-devel. Я почему-то думал, что первое включает второе. Ноу. Мне понадобилось и то, и другое. Дрова счастливо встали, как надо.

Типа в /usr/src должен лежать .config Ткните носом, что делать, куда рыть конкретнее?

На будущее — make prepare

Спасибо. А я попробовал было make config, и офигел от количества вопросов. На сотом, наверное, плюнул и решил поискать другие пути. Не зря.

Кстати еще: в прошлый раз ставил kernel-source из репы. И зипер змей мне впарил сырцы 3.1.10 В то время как

zcat /proc/config.gz > /usr/src/linux/.config && make prepare

Если в /proc/ конфига нету — должен быть в /boot/

А make config — это как make menuconfig, только оно тебя все опции спрашивает само 🙂

Да, этот допрос утомил но и впечатлил, — тонкостью/гибкостью настройки. Хотя даже трети опций не понял. Теперь вполне понимаю профит самопального ядра. По идее можно пилить ядро под конкретную машину, без лишних модулей, с минимальным весом и четко подобранным под род деятельности функционалом. Хочешь — сервак с блекджеком и шлюхами, а хочешь, минимальное ядро для флешки. При этом достаточно просто представлять себе смысл опций, и тыкать [y/n], ковыряться в коде не приходится. Мда, пингвинье дао пингвинье

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

Ну и что непонятного во фразе The most likely reason for this is that the kernel source files in ‘/usr/src/linux’ have not been configured ?

Источник

Работа с файлами устройств (запись и IOCTL)

Файлы устройства представляют физические устройства. Многие физические устройства используются для вывода и для ввода, так должен иметься некоторый механизм для драйверов устройства в ядре, чтобы послать вывод устройству из процесса. Это выполняется, открывая файл устройства для вывода и записывая в него точно так же, как в обычный файл. В следующем примере, это выполнено функцией device_write .

Этого не всегда достаточно. Вообразите, что Вы имеете последовательный порт, связанный с модемом (даже если Вы имеете внутренний модем, он выглядит с точки зрения CPU как последовательный порт, связанный с модемом, так что Вы не должны слишком сдерживать Ваше воображение). Естественное решение использовать файл устройства, чтобы передавать модему команды модема или данные, которые будут посланы через телефонную линию и читать из модема ответы для команд или данные, полученные через телефонную линию. Однако, это оставляет открытым вопрос о том что делать, когда Вы должны работать с последовательным портом непосредственно, например настроить скорость обмена данными с портом.

Ответ в Unix должен использовать специальную функцию, названную ioctl (сокращение от input output control). Каждое устройство может иметь собственные команды ioctl , которые могут читать ioctl (для передачи данных от процесса ядру), записывать ioctl (чтобы возвратить информацию процессу), 5.1 , выполнять оба действия или ни одно из них. Функция ioctl вызывается с тремя параметрами: описатель файла соответствующий файлу устройства, ioctl номер, и параметра, который имеет тип long, так что Вы можете использовать приведение, чтобы передать что-нибудь. 5.2

Ioctl номер кодирует главный номер устройства, тип ioctl команды и тип параметра. Этот ioctl номер обычно создается макрообращением ( _IO , _IOR , _IOW или _IOWR : в зависимости от типа) в файле заголовка. Этот файл заголовка должен быть присоединен командой #include программой, которая использует ioctl и модулем (так что они могут генерировать соответствующие ioctl ). В примере ниже, файл заголовка chardev.h и программа, которая использует это ioctl.c .

Источник

Пишем простой модуль ядра Linux

Захват Золотого Кольца-0

Linux предоставляет мощный и обширный API для приложений, но иногда его недостаточно. Для взаимодействия с оборудованием или осуществления операций с доступом к привилегированной информации в системе нужен драйвер ядра.

Модуль ядра Linux — это скомпилированный двоичный код, который вставляется непосредственно в ядро Linux, работая в кольце 0, внутреннем и наименее защищённом кольце выполнения команд в процессоре x86–64. Здесь код исполняется совершенно без всяких проверок, но зато на невероятной скорости и с доступом к любым ресурсам системы.

Не для простых смертных

Написание модуля ядра Linux — занятие не для слабонервных. Изменяя ядро, вы рискуете потерять данные. В коде ядра нет стандартной защиты, как в обычных приложениях Linux. Если сделать ошибку, то повесите всю систему.

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

Можно в основном забыть традиционные парадигмы разработки приложений. Кроме загрузки и выгрузки модуля, вы будете писать код, который реагирует на системные события, а не работает по последовательному шаблону. При работе с ядром вы пишете API, а не сами приложения.

У вас также нет доступа к стандартной библиотеке. Хотя ядро предоставляет некоторые функции вроде printk (которая служит заменой printf ) и kmalloc (работает похоже на malloc ), в основном вы остаётесь наедине с железом. Вдобавок, после выгрузки модуля следует полностью почистить за собой. Здесь нет сборки мусора.

Необходимые компоненты

Прежде чем начать, следует убедиться в наличии всех необходимых инструментов для работы. Самое главное, нужна машина под Linux. Знаю, это неожиданно! Хотя подойдёт любой дистрибутив Linux, в этом примере я использую Ubuntu 16.04 LTS, так что в случае использования других дистрибутивов может понадобиться слегка изменить команды установки.

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

И наконец, нужно хотя бы немного знать C. Рабочая среда C++ слишком велика для ядра, так что необходимо писать на чистом голом C. Для взаимодействия с оборудованием не помешает и некоторое знание ассемблера.

Установка среды разработки

На Ubuntu нужно запустить:

Устанавливаем самые важные инструменты разработки и заголовки ядра, необходимые для данного примера.

Примеры ниже предполагают, что вы работаете из-под обычного пользователя, а не рута, но что у вас есть привилегии sudo. Sudo необходима для загрузки модулей ядра, но мы хотим работать по возможности за пределами рута.

Начинаем

Приступим к написанию кода. Подготовим нашу среду:

Запустите любимый редактор (в моём случае это vim) и создайте файл lkm_example.c следующего содержания:

Мы сконструировали самый простой возможный модуль, рассмотрим подробнее самые важные его части:

• В include перечислены файлы заголовков, необходимые для разработки ядра Linux.
• В MODULE_LICENSE можно установить разные значения, в зависимости от лицензии модуля. Для просмотра полного списка запустите:

Мы устанавливаем init (загрузка) и exit (выгрузка) как статические функции, которые возвращают целые числа.

Обратите внимание на использование printk вместо printf . Также параметры printk отличаются от printf . Например, флаг KERN_INFO для объявления приоритета журналирования для конкретной строки указывается без запятой. Ядро разбирается с этими вещами внутри функции printk для экономии памяти стека.

В конце файла можно вызвать module_init и module_exit и указать функции загрузки и выгрузки. Это даёт возможность произвольного именования функций.

Впрочем, пока мы не можем скомпилировать этот файл. Нужен Makefile. Такого базового примера пока достаточно. Обратите внимание, что make очень привередлив к пробелам и табам, так что убедитесь, что используете табы вместо пробелов где положено.

Если мы запускаем make , он должен успешно скомпилировать наш модуль. Результатом станет файл lkm_example.ko . Если выскакивают какие-то ошибки, проверьте, что кавычки в исходном коде установлены корректно, а не случайно в кодировке UTF-8.

Теперь можно внедрить модуль и проверить его. Для этого запускаем:

Если всё нормально, то вы ничего не увидите. Функция printk обеспечивает выдачу не в консоль, а в журнал ядра. Для просмотра нужно запустить:

Вы должны увидеть строку “Hello, World!” с меткой времени в начале. Это значит, что наш модуль ядра загрузился и успешно сделал запись в журнал ядра. Мы можем также проверить, что модуль ещё в памяти:

Для удаления модуля запускаем:

Если вы снова запустите dmesg, то увидите в журнале запись “Goodbye, World!”. Можно снова запустить lsmod и убедиться, что модуль выгрузился.

Как видите, эта процедура тестирования слегка утомительна, но её можно автоматизировать, добавив:

в конце Makefile, а потом запустив:

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

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

Немного интереснее

Копнём чуть глубже. Хотя модули ядра способны выполнять все виды задач, взаимодействие с приложениями — один из самых распространённых вариантов использования.

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

Вероятно, раньше вы уже имели дело с файлами устройств. Команды с упоминанием /dev/zero , /dev/null и тому подобного взаимодействуют с устройствами “zero” и “null”, которые возвращают ожидаемые значения.

В нашем примере мы возвращаем “Hello, World”. Хотя это не особенно полезная функция для приложений, она всё равно демонстрирует процесс взаимодействия с приложением через файл устройства.

Вот полный листинг:

Тестирование улучшенного примера

Теперь наш пример делает нечто большее, чем просто вывод сообщения при загрузке и выгрузке, так что понадобится менее строгая процедура тестирования. Изменим Makefile только для загрузки модуля, без его выгрузки.

Теперь после запуска make test вы увидите выдачу старшего номера устройства. В нашем примере его автоматически присваивает ядро. Однако этот номер нужен для создания нового устройства.

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

(в этом примере замените MAJOR значением, полученным в результате выполнения make test или dmesg )

Параметр c в команде mknod говорит mknod, что нам нужно создать файл символьного устройства.

Теперь мы можем получить содержимое с устройства:

или даже через команду dd :

Вы также можете получить доступ к этому файлу из приложений. Это необязательно должны быть скомпилированные приложения — даже у скриптов Python, Ruby и PHP есть доступ к этим данным.

Когда мы закончили с устройством, удаляем его и выгружаем модуль:

Заключение

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

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

Источник