/ include vs / include / linux в дереве исходного кода ядра
С вводом file.txt :
Sample-pattern="abc"
Sample2-pattern="xyz"
Sample3pattern="def"
Следующий сценарий sed выдаст такой результат:
$ sed -E -n -e '/-pattern/ s/^([^-]*)-[^=]*="([^"]*)"/\1 \2/p' file.txt
Sample abc
Sample2 xyz
Сценарий sed выше печатает весь текст перед первым символом - в строке И весь текст внутри двойных кавычек после первого символа = в строке. . Он не печатает строки, которые не соответствуют регулярным выражениям (обе - спецификация адреса / - pattern / и s /// поиск и замена).
ПРИМЕЧАНИЕ. Для включения расширенных регулярных выражений используется параметр -E в sed . Это работает с GNU, * BSD, Mac OS X и некоторыми другими версиями sed .... лучше использовать -E , чем GNU-ish - r , который делает то же самое, но не реализован в версии sed для Mac OS X. -E , скорее всего, в недалеком будущем станет стандартом POSIX.
Базовая версия регулярного выражения будет выглядеть так:
sed -n -e '/-pattern/ s/^\([^-]*\)-[^=]*="\([^"]*\)"/\1 \2/p'
Но не только linux/, но и uapi/и asm-generic/являются специальными каталогами внутри include. Этот общий «включаемый» каталог является гетерогенным--include/linuxи представляет собой само ядро :наполовину из 40 МБ include/.
K&R "C" отмечает в конце главы :"...для гораздо более крупной программы потребуется больше организации и больше заголовков".
Итак, с самого начала, в том числе и в проектах среднего размера, все зависит от организации. Это также отражено в синтаксисе <.h>и ".h"и правилах включения компилятора. Также по #ifndef... #define«защите», которая применяется систематически. Ядро Linux имеет намного лучшую организацию.
Кажется, я наконец-то нашел работающий пример:
kernel/sched/сам по себе имеет размеры от малых до средних. Он имеет 8 заголовочных файлов, один из них sched.h, который начинается:
/*
* Scheduler internal types and methods:
*/
#include <linux/sched.h>
...
Этот "локальный" файл sched.h содержит только элементы низкого уровня.
Это включает include/linux/sched.hначало:
#ifndef _LINUX_SCHED_H
#define _LINUX_SCHED_H
/*
* Define 'struct task_struct' and provide the main scheduler
* APIs (schedule(), wakeup variants, etc.)
*/
#include <uapi/linux/sched.h>
#include <asm/current.h>
#include <linux/pid.h>
...
Все это на самом деле очень хорошо задокументировано и изложено.
«uapi» включает в себя определение флагов CLONE _и политик SCHED _(, например. RR=2 ):для "экспорта"/использования программами.
asm/current.h— низкий уровень для доступа к текущей задаче.
linux/pid.has sibling так же элементарна, как linux/sched.h.
--> include/linux/— главный центральный контейнер для глобальных заголовочных файлов «ядра».
Другие каталоги --и большие остальные --в include/частично предназначены для «импорта» определений, т. е. интеграции аппаратного обеспечения. Они больше относятся к драйверам/, чем к ядру/ или mm/ или fs/.
include/sound/тоже интересно.sound/sound_core.cесть:
/*
* First, the common part.
*/
#include <linux/module.h>
#include <linux/device.h>
#include <linux/err.h>
#include <linux/kdev_t.h>
#include <linux/major.h>
#include <sound/core.h>
Так что ему нужны (linux -, модули ядра -), ошибки и устройства, а также собственный «Главный заголовочный файл для устройств драйвера ALSA... (1994 -2001 )sound/core.h.