inotify

title: inotify(7)

summary: наблюдает за событиями файловой системы

text:
# inotify(7)

## ИМЯ
inotify - наблюдает за событиями файловой системы

## ОПИСАНИЕ
Программный интерфейс inotify предоставляет механизм для слежения за событиями в файловой системе. Его можно использовать для слежения за отдельными файлами или каталогами. При слежении за каталогами inotify возвращает события как для самого каталога, так и для файлов внутри каталога.

В программный интерфейс входят следующие системные вызовы:

- Вызов inotify_init(2) создаёт экземпляр inotify и возвращает файловый дескриптор, ссылающийся на экземпляр inotify. Более новый inotify_init1(2) подобен inotify_init(2), но имеет аргумент flags, который предоставляет доступ к некоторым дополнительным возможностям.

- Вызов inotify_add_watch(2) изменяет «список наблюдения», связанный с экземпляром inotify. Каждый элемент (сторожок (watch)) в списке задаёт путь к файлу или каталогу и некоторый набор событий, которые ядро должно отслеживать для файла, на который указывает этот путь. Вызов inotify_add_watch(2) или создаёт новый сторожок, или изменяет существующий. Каждый сторожок имеет уникальный «дескриптор сторожка» — целое число, возвращаемое inotify_add_watch(2) при создании сторожка.

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

- Вызов inotify_rm_watch(2) удаляет элемент из списка наблюдения inotify.

- При закрытии (с помощью close(2)) файловых дескрипторов, ссылающихся на экземпляр inotify, этот объект и его ресурсы освобождаются для повторного использования ядром; все связанные сторожки освобождаются автоматически.

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

### Чтение событий из файлового дескриптора inotify
Чтобы определить, что события произошли, приложение должно прочитать (read(2)) файловый дескриптор inotify. Если событий не было, то предполагая, что это блокирующий файловый дескриптор, вызов read(2) заблокирует работу до возникновения, по крайней мере, одного события (если не будет прерван сигналом; в этом случае вызов завершается с ошибкой EINTR, смотрите signal(7)).

При успешном выполнении read(2) возвращает буфер с одной или более структурами следующего вида:

```
struct inotify_event {

    int      wd;       /* дескриптор наблюдаемого */

    uint32_t mask;     /* маска, описывающая событие */

    uint32_t cookie;   /* уникальный cookie, связывающий относящиеся

                          друг к другу события (для rename(2)) */

    uint32_t len;      /* размер поля name */

    char     name[];   /* необязательное имя, завершающееся null */
};
```

В wd указывается сторожок, к которому относится событие. Это один из дескрипторов сторожка, полученный из вызова inotify_add_watch(2).

В mask содержатся биты, описывающие возникшее событие (смотрите ниже).

Значение cookie — это уникальное целое, которое объединяет связанные события. В настоящее время используется только для событий переименования и позволяет приложению объединить возвращаемые IN_MOVED_FROM и IN_MOVED_TO в пару событий. Для остальных типов событий значение cookie равно 0.

Поле name существует только когда событие возвращается для файла внутри отслеживаемого каталога; им определяется имя файла внутри отслеживаемого каталога. Это имя завершается null и может включать дополнительные байты null («\0») для выравнивания на подходящую границу адреса при последующих операций чтения.

Поле len содержит количество всех байт в name, включая байты null; длина каждой структуры inotify_event равна sizeof(struct inotify_event)+len.

Если буфер, заданный в read(2), слишком мал для возврата информации о следующем событии, то поведение зависит от версии ядра: в ядрах до версии 2.6.21, read(2) возвращает 0; начиная с версии 2.6.21, read(2) завершается с ошибкой EINVAL. Указание размера буфера

sizeof(struct inotify_event) + NAME_MAX + 1

будет достаточно для чтения, по крайней мере, одного события.

### События inotify
В аргументе inotify_add_watch(2) mask и поле mask структуры inotify_event, возвращаемых при чтении файлового дескриптора inotify, содержатся битовые маски, определяющие события inotify. Следующие биты могут быть заданы в mask при вызове inotify_add_watch(2) и возвращены в поле mask, возвращаемом read(2):

IN_ACCESS (+)

Был произведён доступ к файлу (например, read(2), execve(2)).

IN_ATTRIB (*)

Изменились метаданные — например, права доступа (например, chmod(2)), отметки времени (например, utimensat(2)), расширенные атрибуты (setxattr(2)), счётчик ссылок (начиная с Linux 2.6.25; например, для аргумента назначения link(2) и unlink(2)) и идентификатор пользователя/группы (например, chown(2)).

IN_CLOSE_WRITE (+)

Файл, открытый для записи, был закрыт.

IN_CLOSE_NOWRITE (*)

Файл или каталог, не открытый для записи, был закрыт.

IN_CREATE (+)

В отслеживаемом каталоге был создан файл/каталог (например, open(2) O_CREAT, mkdir(2), link(2), symlink(2), bind(2) для доменного сокета UNIX).

IN_DELETE (+)

В отслеживаемом каталоге был удалён файл/каталог.

IN_DELETE_SELF

Отслеживаемый файл/каталог был удалён (это событие также возникает, если объект перемещён в другую файловую систему, так как mv(1), фактически, копирует файл в другую файловую систему и удаляет его из исходной). Также затем будет создано событие IN_IGNORED для дескриптора сторожка.

IN_MODIFY (+)

Файл был изменён (например, write(2), truncate(2)).

IN_MOVE_SELF

Отслеживаемый файл/каталог был перемещён.

IN_MOVED_FROM (+)

При переименовании генерируется для каталога, содержащего старое имя файла.

IN_MOVED_TO (+)

При переименовании генерируется для каталога, содержащего новое имя файла.

IN_OPEN (*)

Файл или каталог был открыт.

Наблюдение inotify ведётся за inode: при наблюдении за файлом (но не когда наблюдение ведётся за каталогом, содержащим файл) событие может генерироваться при активности по любой ссылке на файл (находящейся в том же или в другом каталоге).

При наблюдении за каталогом:

- события, помеченные звёздочкой (*), могут возникать как для самого каталога, так и для файлов в каталоге; и

- события, помеченные знаком плюс (+), могут возникать только для объектов внутри каталога (но не самого каталога).

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

Когда события генерируются для объектов внутри отслеживаемого каталога, поле name, возвращаемое в структуре inotify_event, хранит имя файла внутри этого каталога.

Макрос IN_ALL_EVENTS определён как битовая маска всех перечисленных выше событий. Данный макрос можно использовать в качестве аргумента mask в вызове inotify_add_watch(2).

Дополнительно, два удобных макроса:

IN_MOVE

То же, что и IN_MOVED_FROM | IN_MOVED_TO.

IN_CLOSE

То же, что и IN_CLOSE_WRITE | IN_CLOSE_NOWRITE.

Также, при вызове inotify_add_watch(2) в mask могут быть указаны следующие биты:

IN_DONT_FOLLOW (начиная с Linux 2.6.15)

Не разыменовывать pathname, если это символическая ссылка.

IN_EXCL_UNLINK (начиная с Linux 2.6.36)

По умолчанию, при слежении за событиями для потомков каталога, события генерируются для потомков даже после того, как они будут удалены из каталога. Это может привести к большому количеству ненужных для приложения событий (например, если следить за /tmp, в котором многие приложения создают и сразу удаляют временные файлы). Указание IN_EXCL_UNLINK изменяет поведение по умолчанию, и такие события не генерируются для потомков после удаления из отслеживаемого каталога.

IN_MASK_ADD

Если экземпляр слежения уже существует для объекта файловой системы соответствующего pathname, то выполнять добавление (OR) событий в mask к маске слежения (вместо замены маски); если также указан IN_MASK_CREATE, то возвращается ошибка EINVAL.

IN_ONESHOT

Отслеживать объект файловой системы, соответствующий pathname до одного события, затем удалить объект из списка слежения.

IN_ONLYDIR (начиная с Linux 2.6.15)

Следить за pathname, только если это каталог; если pathname не является каталогом, то возвращается ошибка ENOTDIR. Этот флаг предоставляет приложению бессостязательный способ убедиться, что отслеживаемый объект — каталог.

IN_MASK_CREATE (начиная с Linux 4.18)

Следить за pathname только, если за ним никто не следит; если уже выполняется слежение за pathname, то возвращается ошибка EEXIST.

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

Следующие биты могут быть установлены в поле mask при возврате из read(2):

IN_IGNORED

Слежение было снято явно (inotify_rm_watch(2)) или автоматически (файл был удалён или размонтирована файловая система). Также смотрите ДЕФЕКТЫ.

IN_ISDIR

Объект этого события — каталог.

IN_Q_OVERFLOW

Переполнена очередь событий (для этого события значение wd равно -1).

IN_UNMOUNT

Файловая система, содержащая отслеживаемый объект, была размонтирована. Также, будет сгенерировано событие IN_IGNORED для дескриптора сторожка.

### Примеры
Предположим, приложение следит за всеми событиями для каталога dir и файла dir/myfile. В примере ниже показаны некоторые события, которые будут сгенерированы для этих двух объектов.

fd = open("dir/myfile", O_RDWR);

Генерируется событие IN_OPEN и для dir, и для dir/myfile.

read(fd, buf, count);

Генерируется событие IN_ACCESS и для dir, и для dir/myfile.

write(fd, buf, count);

Генерируется событие IN_MODIFY и для dir, и для dir/myfile.

fchmod(fd, mode);

Генерируется событие IN_ATTRIB и для dir, и для dir/myfile.

close(fd);

Генерируется событие IN_CLOSE_WRITE и для dir, и для dir/myfile.

Предположим, приложение следит за всеми событиями для каталогов dir1 и dir2 и файла dir1/myfile. В примере ниже показаны некоторые события, которые могут быть сгенерированы.

link("dir1/myfile", "dir2/new");

Генерируется событие IN_ATTRIB для myfile и событие IN_CREATE для dir2.

rename("dir1/myfile", "dir2/myfile");

Генерируется событие IN_MOVED_FROM для dir1, событие IN_MOVED_TO для dir2 и событие IN_MOVE_SELF для myfile. События IN_MOVED_FROM и IN_MOVED_TO будут содержать одинаковое значение cookie.

Предположим, что dir1/xx и dir2/yy только ссылки на один файл и приложение следит за dir1, dir2, dir1/xx и dir2/yy. При выполнение следующих вызовов в порядке, указанном ниже, будут сгенерированы следующие события:

unlink("dir2/yy");

Генерируется событие IN_ATTRIB для xx (так как изменился его счётчик ссылок) и событие IN_DELETE для dir2.

unlink("dir1/xx");

Генерируется событие IN_ATTRIB, IN_DELETE_SELF и IN_IGNORED для xx и событие IN_DELETE для dir1.

Предположим, приложение следит за каталогом dir и пустым каталогом dir/subdir. В примере ниже показаны некоторые события, которые могут быть сгенерированы.

mkdir("dir/new", mode);

Генерируется событие IN_CREATE | IN_ISDIR для dir.

rmdir("dir/subdir");

Генерируются события IN_DELETE_SELF и IN_IGNORED для subdir и событие IN_DELETE | IN_ISDIR для dir.

### Интерфейсы в /proc
Для ограничения потребления inotify памяти ядра, можно использовать следующие интерфейсы:

/proc/sys/fs/inotify/max_queued_events

Значение в этом файле используется когда приложение вызывает inotify_init(2) для установки верхнего порога количества событий, которые могут поместиться в очередь соответствующего экземпляра inotify. События, превысившие это ограничение, отбрасываются, но событие IN_Q_OVERFLOW генерируется всегда.

/proc/sys/fs/inotify/max_user_instances

В этом файле задаётся ограничение на количество экземпляров inotify, которые могут быть созданы для одного реального идентификатора пользователя.

/proc/sys/fs/inotify/max_user_watches

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

## ВЕРСИИ
Программный интерфейс inotify был добавлен в ядро Linux версии 2.6.13. Необходимые библиотечные интерфейсы добавлены в glibc версии 2.4 (IN_DONT_FOLLOW, IN_MASK_ADD и IN_ONLYDIR добавлены в glibc версии 2.5).

## СООТВЕТСТВИЕ СТАНДАРТАМ
Программный интерфейс inotify есть только в Linux.

## ЗАМЕЧАНИЯ
За файловыми дескрипторами inotify можно наблюдать с помощью select(2), poll(2), и epoll(7). Когда возникает событие, файловый дескриптор указывает на возможность чтения.

Начиная с Linux 2.6.25, для файловых дескрипторов inotify стали доступны уведомления ввода-вывода посредством сигналов; смотрите обсуждение F_SETFL (для установки флага O_ASYNC), F_SETOWN и F_SETSIG в fcntl(2). Структура siginfo_t (описана в sigaction(2)), передаваемая обработчику сигнала, содержит следующие настройки полей: в si_fd указывается номер файлового дескриптора inotify; в si_signo указывается номер сигнала; в si_code указывается POLL_IN; в si_band указывается POLLIN.

Если последующие события inotify, выводимые в файловый дескриптор inotify, одинаковы (содержат одинаковые значения wd, mask, cookie и name), то они сливаются в одно событие, если самое старое событие ещё не прочитано (но смотрите ДЕФЕКТЫ). Это сокращает требуемое количество памяти ядра для очереди событий, но также означает, что приложение не может использовать inotify для надёжного подсчёта файловых событий.

События, возвращаемые при чтении из файлового дескриптора inotify, формируют упорядоченную очередь. То есть, например, это гарантирует, что при переименовании одного каталога в другой, события в файловом дескрипторе inotify будут созданы в правильном порядке.

Набор наблюдаемых дескрипторов, которые отслеживаются через файловый дескриптор inotify, можно увидеть из записи для файлового дескриптора inotify в каталоге процесса /proc/[pid]/fdinfo. Дополнительную информацию смотрите в proc(5). Вызов FIONREAD ioctl(2) возвращает количество байт, доступных для чтения из файлового дескриптора inotify.

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

Inotify сообщает только о событиях, которые возникли из-за пользовательских программ, использовавших программный интерфейс файловой системы. То есть, не возникает событий для файловых систем, доступных по сети (приложения должны использовать старый метод опроса файловой системы для слежения за такими событиями). Кроме того, различные псевдо-файловый системы, такие как /proc, /sys и /dev/pts, не отслеживаются через inotify.

Программный интерфейс inotify не сообщает о доступе и изменениях, которые могут произойти из-за mmap(2), msync(2) и munmap(2).

Программный интерфейс inotify в качестве идентификаторов объектов использует имена файлов. Однако, в момент обработки приложением события inotify, имя файла может быть уже удалено или переименовано.

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

Отслеживание каталогов через inotify ведётся не рекурсивно: чтобы отслеживать подкаталоги, нужно создать дополнительные сторожки. Это может занять много времени при большом дереве каталога.

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

Заметим, что очередь событий может переполниться. В этом случае события теряются. Корректные приложения должны учитывать возможность пропажи событий. Например, может потребоваться перестроить часть или весь кэш приложения (один простой, но, возможно, затратный способ, это закрыть файловый дескриптор inotify, опустошить кэш, создать новый файловый дескриптор inotify и затем пересоздать сторожки и записи в кэше для отслеживаемых объектов).

Если файловая система смонтирована поверх отслеживаемого каталога, то событие не генерируются, а также не генерируются события для объектов, находящихся в новой точке монтирования на первом уровне. Если в дальнейшем файловая система отмонтируется, то события начнут генерироваться для каталога и содержащихся в нём объектов.

### Работа с событиями rename()
Как указывалось выше, из событий IN_MOVED_FROM и IN_MOVED_TO, генерируемых rename(2), можно определить пару по их одинаковому значению cookie. Однако, с этой задачей есть несколько проблем.

Эти два события, обычно, стоят друг за другом в потоке событий, если читать из файлового дескриптора inotify. Однако, это не гарантируется. Если несколько процессов создают события для отслеживаемых объектов, то (в редких случаях) произвольное количество других событий может появиться между событиями IN_MOVED_FROM и IN_MOVED_TO. Кроме того, не гарантируется, что пара событий вставляется в очередь атомарно: может существовать короткий интервал, в котором IN_MOVED_FROM уже появилось, а IN_MOVED_TO ещё нет.

Соответствие IN_MOVED_FROM и IN_MOVED_TO паре событий, сгенерированных rename(2), по сути, просто (не забудьте, что если объект переименовывается вне отслеживаемого каталога, то может не быть даже события IN_MOVED_TO). Можно использовать эвристические предположения (например, что события всегда следуют друг за другом), что работает в большинстве случаев, но неминуемо не сработает в некоторых случаях, в которых приложение посчитает события IN_MOVED_FROM и IN_MOVED_TO несвязными. Если в результате дескрипторы сторожков будут уничтожены и пересозданы, то такие дескрипторы будут несогласованны с дескрипторами сторожков для любых ожидающих событий (пересоздание файлового дескриптора inotify и пересборка кэша может быть полезна в этом случае).

Также приложения должны учитывать возможность того, что событие IN_MOVED_FROM — последнее событие, которое попало в буфер, возвращаемый текущим вызовом read(2), и сопутствующее событие IN_MOVED_TO может быть получено только при следующем чтении read(2), которое должно быть выполнено с (коротким) промежутком, позволяющим фактическую не атомарную вставку пары событий IN_MOVED_FROM-IN_MOVED_TO, и также возможность того, что может отсутствовать событие IN_MOVED_TO.

## ДЕФЕКТЫ
До Linux 3.19, fallocate(2) не создавал события inotify. Начиная с Linux 3.19, вызов fallocate(2) генерирует событие IN_MODIFY.

В ядрах до 2.6.16 флаг IN_ONESHOT в mask не работает.

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

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

Когда дескриптор сторожка удаляется вызовом inotify_rm_watch(2) (или из-за удаления отслеживаемого файла, или размонтирования содержащей его файловой системы), все ожидающие непрочитанные события для этого дескриптора сторожка остаются доступными для чтения. Так как дескрипторы сторожков в дальнейшем циклически выделяются inotify_add_watch(2), ядро поступательно проходит через диапазон возможных дескрипторов сторожков (от 0 до INT_MAX). При выделении свободного дескриптора сторожка для выбранного номера не производится проверка того, есть ли какие-то ожидающие непрочитанные события в очереди inotify с таким номером или нет. То есть может случиться так, что дескриптор сторожка выделяется повторно даже когда существуют ожидающие непрочитанные события, оставшиеся от предыдущего выделения дескриптора сторожка с тем же номером; в результате приложение может прочесть эти события и посчитать их как принадлежащие файлу, связанному с новым повторно задействованным дескриптором сторожка. На практике, вероятность столкновения с этой ошибкой может быть чрезвычайно низка, так как для этого требуется, чтобы приложения циклически перебрало все INT_MAX дескрипторов сторожков, освободило дескриптор сторожка и оставило непрочитанные события этого дескриптора сторожка в очереди, а затем повторно задействовало этот дескриптор сторожка. По этой причине и из-за того, что ещё никто не сообщал об этой ошибке в реальности, на момент актуальности Linux 3.15, в ядре ничего не было сделано для того, чтобы устранить этот дефект.

## ПРИМЕР
Следующая программа демонстрирует использование программного интерфейса inotify. Она помечает каталоги, переданной в аргументах командной строки, и ждёт событий с типом IN_OPEN, IN_CLOSE_NOWRITE и IN_CLOSE_WRITE.

Следующий вывод был записан при редактировании файла /home/user/temp/foo и просмотра каталога /tmp. Перед открытием файла и каталога произошли события IN_OPEN. После закрытия файла произошло событие IN_CLOSE_WRITE. После закрытия каталога произошло событие IN_CLOSE_NOWRITE. Выполнение программы закончилось после нажатия пользователем клавиши ENTER.

### Пример вывода

```
$ ./a.out /tmp /home/user/temp
Нажмите ENTER для завершения работы.
Ожидание событий.
IN_OPEN: /home/user/temp/foo [файл]
IN_CLOSE_WRITE: /home/user/temp/foo [файл]
IN_OPEN: /tmp/ [каталог]
IN_CLOSE_NOWRITE: /tmp/ [каталог]
Ожидание событий прекращено.
```

### Исходный код программы

```
#include <errno.h>
#include <poll.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/inotify.h>
#include <unistd.h>
/* Читаем все доступные события из файлового дескриптора «fd».

   wd — таблица дескрипторов сторожков для каталогов из argv.

   argc — длина wd и argv.

   argv — список наблюдаемых каталогов.

   Элемент 0 в wd и argv не используется. */
static void
handle_events(int fd, int *wd, int argc, char* argv[])
{

    /* В некоторых системах невозможно прочитать целые переменные, если

       они неправильно выровнены. В других системах некорректное

       выравнивание может снижать производительность. Таким образом, буфер,

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

       выровнен также как структура struct inotify_event. */

    char buf[4096]

        __attribute__ ((aligned(__alignof__(struct inotify_event))));

    const struct inotify_event *event;

    int i;

    ssize_t len;

    char *ptr;

    /* проходим по всем событиям, которые можем прочитать

       из файлового дескриптора inotify */

    for (;;) {

        /* читаем несколько событий */

        len = read(fd, buf, sizeof buf);

        if (len == -1 && errno != EAGAIN) {

            perror("read");

            exit(EXIT_FAILURE);

        }

        /* Если неблокирующий read() не найдёт событий для чтения, то

           вернёт -1 с errno равным EAGAIN. В этом случае

           выходим из цикла. */

        if (len <= 0)

            break;

        /* проходим по всем событиям в буфере */

        for (ptr = buf; ptr < buf + len;

                ptr += sizeof(struct inotify_event) + event->len) {

            event = (const struct inotify_event *) ptr;

            /* печатаем тип события */

            if (event->mask & IN_OPEN)

                printf("IN_OPEN: ");

            if (event->mask & IN_CLOSE_NOWRITE)

                printf("IN_CLOSE_NOWRITE: ");

            if (event->mask & IN_CLOSE_WRITE)

                printf("IN_CLOSE_WRITE: ");

            /* печатаем имя наблюдаемого каталога */

            for (i = 1; i < argc; ++i) {

                if (wd[i] == event->wd) {

                    printf("%s/", argv[i]);

                    break;

                }

            }

            /* печатаем имя файла */

            if (event->len)

                printf("%s", event->name);

            /* печатаем тип объекта файловой системы */

            if (event->mask & IN_ISDIR)

                printf(" [каталог]\n");

            else

                printf(" [файл]\n");

        }

    }
}
int
main(int argc, char* argv[])
{

    char buf;

    int fd, i, poll_num;

    int *wd;

    nfds_t nfds;

    struct pollfd fds[2];

    if (argc < 2) {

        printf("Использование: %s ПУТЬ [ПУТЬ …]\n", argv[0]);

        exit(EXIT_FAILURE);

    }

    printf("Нажмите ENTER для завершения работы.\n");

    /* Создаём файловый дескриптор для доступа к inotify API */

    fd = inotify_init1(IN_NONBLOCK);

    if (fd == -1) {

        perror("inotify_init1");

        exit(EXIT_FAILURE);

    }

    /* выделяем память под дескрипторы сторожков */

    wd = calloc(argc, sizeof(int));

    if (wd == NULL) {

        perror("calloc");

        exit(EXIT_FAILURE);

    }

    /* помечаем каталоги для событий

       - файл был открыт

       - файл был закрыт */

    for (i = 1; i < argc; i++) {

        wd[i] = inotify_add_watch(fd, argv[i],

                                  IN_OPEN | IN_CLOSE);

        if (wd[i] == -1) {

            fprintf(stderr, "Невозможно пронаблюдать '%s'\n", argv[i]);

            perror("inotify_add_watch");

            exit(EXIT_FAILURE);

        }

    }

    /* подготовка к опросу */

    nfds = 2;

    /* ввод с консоли  */

    fds[0].fd = STDIN_FILENO;

    fds[0].events = POLLIN;

    /* ввод inotify */

    fds[1].fd = fd;

    fds[1].events = POLLIN;

    /* ждём события и/или ввода с терминала */

    printf("Ожидание событий.\n");

    while (1) {

        poll_num = poll(fds, nfds, -1);

        if (poll_num == -1) {

            if (errno == EINTR)

                continue;

            perror("poll");

            exit(EXIT_FAILURE);

        }

        if (poll_num > 0) {

            if (fds[0].revents & POLLIN) {

                /* доступен ввод с консоли: опустошаем stdin и выходим */

                while (read(STDIN_FILENO, &buf, 1) > 0 && buf != '\n')

                    continue;

                break;

            }

            if (fds[1].revents & POLLIN) {

                /* доступны события inotify */

                handle_events(fd, wd, argc, argv);

            }

        }

    }

    printf("Ожидание событий прекращено.\n");

    /* закрываем файловый дескриптор inotify */

    close(fd);

    free(wd);

    exit(EXIT_SUCCESS);
}
```

## СМОТРИТЕ ТАКЖЕ
inotifywait(1), inotifywatch(1), inotify_add_watch(2), inotify_init(2), inotify_init1(2), inotify_rm_watch(2), read(2), stat(2), fanotify(7)

Файл Documentation/filesystems/inotify.txt в дереве исходного кода ядра Linux


intro

package: man-pages-ru

title: intro(7)

text:
# intro(7)

## ИМЯ
intro - введение к разделу общих сведений и другой информации

## ОПИСАНИЕ
В разделе 7 представлены общие сведения по различным вопросам, описываются соглашения и протоколы, стандарты кодировок, стандартное расположение файлов в файловой системе и другая информация.

## ЗАМЕЧАНИЯ

### Авторы и условия распространения
Авторы и условия распространения указаны в заголовке исходной справочной страницы. Заметим, что у разных страниц они могут быть разными! Список русских переводчиков для каждой страницы можно найти в .po файле в исходном коде пакета.

## СМОТРИТЕ ТАКЖЕ
standards(7)


ip

title: ip(7)

summary: реализация протокола IPv4 в Linux

text:
# ip(7)

## ИМЯ
ip - реализация протокола IPv4 в Linux

## ОБЗОР
\#include <sys/socket.h>

\#include <netinet/in.h>

\#include <netinet/ip.h> /* включает предыдущий */

tcp_socket = socket(AF_INET, SOCK_STREAM, 0);

udp_socket = socket(AF_INET, SOCK_DGRAM, 0);

raw_socket = socket(AF_INET, SOCK_RAW, protocol);

## ОПИСАНИЕ
В Linux реализован протокол Интернета (Internet Protocol, IP) версии 4, описанный в RFC 791 и RFC 1122. В модуле ip содержится реализация второго уровня групповых многоадресных сообщений, которая соответствует RFC 1112. Кроме того, в нём имеется маршрутизатор IP с фильтрацией пакетов.

Программный интерфейс совместим с интерфейсом сокетов BSD. Более подробную информацию смотрите в socket(7).

Сокет IP создаётся с помощью socket(2):

socket(AF_INET, socket_type, protocol);

Возможные типы сокета (socket_type): SOCK_STREAM (для открытия сокета tcp(7)), SOCK_DGRAM (для открытия сокета udp(7)), SOCK_RAW (для открытия сокета raw(7) с прямым доступом к протоколу IP). В protocol задаётся протокол IP, который указывается в IP-заголовке принимаемых или отправляемых пакетов. Допустимые значения для параметра protocol: 0 и IPPROTO_TCP — для сокетов TCP, 0 и IPPROTO_UDP — для сокетов UDP. Для SOCK_RAW можно указать любой из IP-протоколов, описанных в RFC 1700 и зарегистрированных в IANA.

Если процесс хочет принимать новые входящие пакеты или соединения, то он должен связать сокет с адресом локального интерфейса с помощью bind(2). Каждый IP-сокет может быть связан только с одной задаваемой локальной парой (адрес, порт). Если в вызове bind(2) указать INADDR_ANY, то сокет будет связан со всеми локальными интерфейсами. При вызове listen(2) для несвязанного сокета происходит автоматическая привязка к произвольно выбранному свободному порту с локальным адресом INADDR_ANY. При вызове connect(2) для несвязанного сокета происходит автоматическая привязка к произвольно выбранному свободному порту или используемому общему порту с локальным адресом INADDR_ANY.

После закрытия связанного локального TCP-сокета его адрес будет недоступен в течение некоторого времени, если только не был установлен флаг SO_REUSEADDR. Следует проявлять осторожность при использовании этого флага, поскольку это делает TCP менее надежным.

### Формат адреса
Адрес IP-сокета определяется как комбинация IP-адреса интерфейса и номера порта. В самом протоколе IP нет номеров портов, они реализуются протоколами более высокого уровня, например udp(7) и tcp(7). У неструктурированных (raw) сокетов номер протокола IP указывается в sin_port.

```
struct sockaddr_in {

    sa_family_t    sin_family; /* семейство адресов: AF_INET */

    in_port_t      sin_port;   /* порт сокета в сетевом порядке

                                  байт */

    struct in_addr sin_addr;   /* Интернет-адрес */
};
/* Интернет-адрес */
struct in_addr {

    uint32_t       s_addr;     /* адрес в сетевом порядке байт */
};
```

Значение sin_family всегда устанавливается в AF_INET. Это обязательно; в Linux 2.2 большая часть сетевых функций возвращает код ошибки EINVAL, если это условие не выполняется. В sin_port указывается номер порта в сетевом порядке байт. Порты, номера которых меньше 1024, называются привилегированными портами (или, иногда, зарезервированными портами). Только привилегированные процессы (в Linux: процессы с мандатом CAP_NET_BIND_SERVICE в пользовательском пространстве имён, управляющим его сетевым пространством имён) могут быть связаны с этими сокетами с помощью bind(2). Заметим, что у неструктурированного протокола IPv4 нет понятия портов как таковых, они реализуются только протоколами более высокого уровня, типа tcp(7) и udp(7).

В sin_addr указывается IP-адрес узла. В поле s_addr структуры struct in_addr содержится адрес интерфейса узла в сетевом порядке байт. Значение in_addr должно быть одним из INADDR_* (например, INADDR_LOOPBACK) установленное htonl(3), или с помощью библиотечных функций inet_aton(3), inet_addr(3), inet_makeaddr(3) или напрямую с помощью преобразователя имён (смотрите gethostbyname(3)).

Адреса IPv4 делятся на однозначные (unicast), широковещательные (broadcast) и многоадресные (multicast). Однозначный адрес указывает на один интерфейс узла, широковещательный адрес указывает на все узлы в сети, а многоадресный указывает на все узлы многоадресной (multicast group). Дейтаграммы могут посылаться или приниматься по широковещательным адресам только, если для сокета установлен флаг SO_BROADCAST. В текущей реализации сокетам, ориентированным на соединения, разрешено иметь только однозначные адреса.

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

Есть несколько специальных адресов: INADDR_LOOPBACK (127.0.0.1) всегда ссылается на локальный узел через интерфейс обратной петли; INADDR_ANY (0.0.0.0) означает любой адрес для связывания; INADDR_BROADCAST (255.255.255.255) означает любой узел и, по историческим причинам, при связывании подобен INADDR_ANY.

### Параметры сокета
IP поддерживает некоторые параметры сокета, относящиеся к протоколу, которые могут быть установлены с помощью setsockopt(2) и прочитаны с помощью getsockopt(2). Значением уровня (level) параметров сокета для IP является IPPROTO_IP. Логический флаг в виде целого числа со значением ноль означает «ложь», другие значения — «истина».

Если сокету передается неправильный параметр, то getsockopt(2) и setsockopt(2) завершаются с ошибкой ENOPROTOOPT.

IP_ADD_MEMBERSHIP (начиная с Linux 1.2)

Присоединиться к многоадресной группе. В аргументе указывается структура ip_mreqn.

```
struct ip_mreqn {

    struct in_addr imr_multiaddr; /* IP-адрес группы */

    struct in_addr imr_address;   /* IP локального

                                     интерфейса */

    int            imr_ifindex;   /* индекс интерфейса */
};
```

В imr_multiaddr содержится адрес многоадресной группы, в которую приложение хочет войти или выйти. Это должен быть правильный адрес многоадресной рассылки (иначе setsockopt(2) завершится с ошибкой EINVAL). В imr_address указывается адрес локального интерфейса, через который система должна войти в многоадресную группу; если указано значение INADDR_ANY, то нужный интерфейс выбирается системой самостоятельно. В imr_ifindex указывается индекс интерфейса, через который нужно войти/выйти в группу imr_multiaddr, или 0, если интерфейс может быть любым.

Структура ip_mreqn доступна только начиная с Linux 2.2. Для совместимости, старая структура ip_mreq (существует с Linux 1.2) по-прежнему поддерживается; она отличается от ip_mreqn только отсутствием поля imr_ifindex (при передаче ядро определяет нужную структуру исходя из размера, переданного в optlen).

IP_ADD_MEMBERSHIP допустим только для setsockopt(2).

IP_ADD_SOURCE_MEMBERSHIP (начиная с Linux 2.4.22 / 2.5.68)

Присоединиться к многоадресной группе и разрешить принимать данные только из указанного источника. Аргументом является структура ip_mreq_source.

```
struct ip_mreq_source {

    struct in_addr imr_multiaddr;  /* IP многоадресной

                                      группы */

    struct in_addr imr_interface;  /* IP-адрес локального

                                      интерфейса */

    struct in_addr imr_sourceaddr; /* IP-адрес многоадресного

                                      источника */
};
```

Структура ip_mreq_source похожа на ip_mreqn, которая описана в разделе о IP_ADD_MEMBERSIP. Поле imr_multiaddr содержит адрес многоадресной группы, к которой приложение хочет подключиться или выйти. Поле imr_interface содержит адрес локального интерфейса, с которого система должна подключаться к многоадресной группе. В поле imr_sourceaddr содержится адрес источника, из которого приложение хочет получать данные.

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

IP_BIND_ADDRESS_NO_PORT (начиная с Linux 4.2)

Информирует ядро, что не требуется резервировать эфемерный порт при использовании bind(2) с номером порта 0. Позднее, порт будет автоматически выбран при connect(2); это позволяет использовать общий исходящий порт пока уникальна связка 4-х значений.

IP_BLOCK_SOURCE (начиная с Linux 2.4.22 / 2.5.68)

Прекратить приём многоадресных данных из указанного источника заданной группы. Это допустимо, если приложение подписывалось на многоадресную группу с помощью IP_ADD_MEMBERSHIP или IP_ADD_SOURCE_MEMBERSHIP.

Аргументом является структура ip_mreq_source, описанная в разделе о IP_ADD_SOURCE_MEMBERSHIP.

IP_DROP_MEMBERSHIP (начиная с Linux 1.2)

Выйти из многоадресной группы. Аргументом является структура ip_mreqn или ip_mreq, описана в IP_ADD_MEMBERSHIP.

IP_DROP_SOURCE_MEMBERSHIP (начиная с Linux 2.4.22 / 2.5.68)

Выйти из указанной группы — то есть прекратить приём данных указанной многоадресной группы, которые поступают из указанного источника. Если приложение подписано на несколько источников одной группы, то данные из оставшихся источников продолжат поступать. Чтобы прекратить приём данных из всех источников сразу, используйте IP_DROP_MEMBERSHIP.

Аргументом является структура ip_mreq_source, описанная в разделе о IP_ADD_SOURCE_MEMBERSHIP.

IP_FREEBIND (начиная с Linux 2.4)

Этот логический параметр позволяет привязаться (если значение равно «истина») к IP-адресу, который не является локальным или (пока) не существует. Это позволяет прослушивать сокет, не имея нижележащего сетевого интерфейса или назначенного динамического IP-адреса, которых может ещё не быть, когда приложение пытается связаться с ним. Этот параметр имеет эквивалентный интерфейс ip_nonlocal_bind (описан далее) в /proc на каждый сокет.

IP_HDRINCL (начиная с Linux 2.0)

Если значение равно «истина», то это означает, что пользователь добавил заголовок IP в начало своих данных. Допустим только для сокетов SOCK_RAW; более подробную информацию смотрите в raw(7). Если этот флаг установлен, то значения, заданные параметрами IP_OPTIONS, IP_TTL и IP_TOS, игнорируются.

IP_MSFILTER (начиная с Linux 2.4.22 / 2.5.68)

Этот параметр предоставляет доступ к расширенному программному интерфейсу фильтрации. Аргументом является структура ip_msfilter.

```
struct ip_msfilter {

    struct in_addr imsf_multiaddr; /* IP-адрес

                                      многоадресной группы */

    struct in_addr imsf_interface; /* IP-адрес локального

                                      интерфейса */

    uint32_t       imsf_fmode;     /* Режим фильтрации */

    uint32_t       imsf_numsrc;    /* Количество источников в

                                      следующем массиве */

    struct in_addr imsf_slist[1];  /* Массив адресов

                                      источников */
};
```

Для задания режима фильтрации существует два макроса — MCAST_INCLUDE и MCAST_EXCLUDE. Также, существует макрос IP_MSFILTER_SIZE(n), которым можно определить количество памяти, требуемой для хранения структуры ip_msfilter с n источниками в списке источников.

Полное описание фильтрации многоадресных источников групп смотрите в RFC 3376.

IP_MTU (начиная с Linux 2.2)

Возвращает известное в данный момент значение MTU маршрута текущего сокета. Возвращается целое число.

Параметр IP_MTU допускается только для getsockopt(2) и может использоваться только для подключённого сокета.

IP_MTU_DISCOVER (начиная с Linux 2.2)

Устанавливает или возвращает значение Path MTU Discovery (обнаружение значения MTU маршрута) для сокета. Если он установлен, то Linux будет производить обнаружение значения MTU маршрута для сокетов SOCK_STREAM согласно RFC 1191. Для сокетов не SOCK_STREAM при значении IP_PMTUDISC_DO у всех исходящих пакетов будет устанавливаться флаг запрета фрагментации. Ответственность за разбивку данных на пакеты согласно размеру MTU, и за выполнение, при необходимости, повторной передачи данных, лежит на пользователе. Ядро будет отвергать пакеты (с ошибкой EMSGSIZE), размер которых больше текущего значения MTU у маршрута. При значении IP_PMTUDISC_WANT дейтаграмма будет фрагментироваться по размеру MTU, если требуется, иначе устанавливается флаг запрета фрагментации.

Системное значение по умолчанию можно переключать между IP_PMTUDISC_WANT и IP_PMTUDISC_DONT, записывая, соответственно, нулевое и ненулевое значение в файл /proc/sys/net/ipv4/ip_no_pmtu_disc. Значение определения маршрута MTU

Значение

IP_PMTUDISC_WANT

Использовать для каждого маршрута своё значение.

IP_PMTUDISC_DONT

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

IP_PMTUDISC_DO

Всегда выполнять обнаружение значения MTU маршрута.

IP_PMTUDISC_PROBE

Установить DF, но игнорировать маршрут MTU.

Если значение Path MTU Discovery задано, то ядро автоматически следит за MTU маршрута для каждого удалённого узла. Когда с некоторым узлом установлено соединение с помощью connect(2), текущее значение MTU маршрута можно легко получить через параметр сокета IP_MTU (например, после возникновения ошибки EMSGSIZE). Значение MTU может со временем меняться. Для сокетов без установления соединения, которые имеют несколько узлов-получателей, новое значение MTU для заданного узла назначения может быть получено с помощью очереди ошибок (смотрите IP_RECVERR). При каждом входящем сообщении об обновлении MTU в очередь будет добавляться новая ошибка.

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

Чтобы запустить процесс обнаружения MTU маршрута для сокетов без установления соединения сначала можно установить большой размер дейтаграммы (с размером заголовка до 64 килобайт) и сокращать его при изменении MTU маршрута.

Чтобы получить начальную оценку MTU маршрута, соедините дейтаграмный сокет с адресом назначения, используя connect(2), и узнайте значение MTU путем вызова getsockopt(2) с параметром IP_MTU.

Возможно реализовать обнаружение MTU согласно RFC 4821 с помощью сокетов типа SOCK_DGRAM или SOCK_RAW, установив значение IP_PMTUDISC_PROBE (доступно, начиная с Linux 2.6.22). В частности, это также полезно для инструментов диагностики, таких как tracepath(8), которым нужно умышленно посылать проверочные пакеты большего размера, чем исследуемый Path MTU.

IP_MULTICAST_ALL (since Linux 2.6.31)

Может использоваться для изменения политики доставки многоадресных сообщений в сокеты, подсоединённые к шаблонному (wildcard) адресу INADDR_ANY. Аргументом является логическое целое (по умолчанию 1). Если значение равно 1, то сокет будет принимать сообщения от всех групп, к которым было выполнено присоединение глобально всей системы. В противном случае будут доставляться сообщения от групп, к которым было выполнено присоединение явным образом(например, с помощью IP_ADD_MEMBERSHIP) на этом сокете.

IP_MULTICAST_IF (начиная с Linux 1.2)

Назначает локальное устройство для многоадресного группового сокета (multicast socket). Аргументом для setsockopt(2) является структура ip_mreqn или ip_mreq (начиная с Linux 3.5), подобная IP_ADD_MEMBERSHIP или структуре in_addr (при передаче ядро определяет нужную структуру исходя из размера, переданного в optlen). Для getsockopt(2) аргументом является структура in_addr.

IP_MULTICAST_LOOP (начиная с Linux 1.2)

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

IP_MULTICAST_TTL (начиная с Linux 1.2)

Устанавливает или возвращает значение времени существования (time-to-live) для многоадресных исходящих из этого сокета пакетов, использующих многоадресную адресацию. Для подобных пакетов очень важно установить наименьшее возможное значение TTL. По умолчанию оно равно 1, это значит, что многоадресные пакеты не выйдут за пределы локальной сети, если только пользовательская программа явно не попросит этого. Значением аргумента является целое число.

IP_NODEFRAG (начиная с Linux 2.6.36)

Если установлен (аргумент не равен нулю), то на уровне netfilter запрещается выполнять переборку (reassembly) исходящих пакетов. Значением аргумента является целое число.

Этот параметр допускается только для сокетов с типом SOCK_RAW.

IP_OPTIONS (начиная с Linux 2.0)

Устанавливает или возвращает параметры IP, которые посылаются с каждым пакетом из данного сокета. Аргументами являются указатель на буфер памяти с этими параметрами и размер параметра. Системный вызов setsockopt(2) устанавливает параметры IP, связанные с сокетом. Для IPv4 максимальный размер параметра IPv4 равен 40 байтам. Все возможные параметры перечислены в RFC 791. Если пакет, устанавливающий соединение с сокетом типа SOCK_STREAM, содержит параметры IP, то эти параметры IP (с инвертированными заголовками маршрутизации) будут использоваться в этом сокете. После установления соединения изменять параметры входящими пакетами запрещено. По умолчанию, обработка всех параметров, связанных с маршрутизацией от источника, отключена, но её можно включить через интерфейс accept_source_route в /proc. Другие параметры, например связанные с временными отметками (timestamp), продолжают обрабатываться. Для дейтаграмных сокетов параметры IP могут быть установлены только локальным пользователем. Вызов getsockopt(2) с параметром IP_OPTIONS помещает в указанный буфер текущие параметры IP, используемые при отправке.

IP_PKTINFO (начиная с Linux 2.2)

Передает вспомогательное (ancillary) сообщение IP_PKTINFO с структурой pktinfo, которая содержит некоторую информацию о входящем пакете. Допускается только для сокетов, ориентированных на посылку дейтаграмм. Аргументом является флаг, который сообщает сокету, нужно ли посылать сообщение IP_PKTINFO или нет. Само сообщение может быть послано/получено только в виде управляющего сообщения с пакетом, используя recvmsg(2) или sendmsg(2).

```
struct in_pktinfo {

    unsigned int   ipi_ifindex;  /* индекс интерфейса */

    struct in_addr ipi_spec_dst; /* локальный адрес */

    struct in_addr ipi_addr;     /* заголовок адреса

                                    назначения */
};

```

ipi_ifindex это уникальный индекс интерфейса, из которого был получен этот пакет. ipi_spec_dst это локальный адрес пакета, а ipi_addr это адрес назначения, указанный в заголовке пакета. Если параметр IP_PKTINFO передаётся в sendmsg(2) и ipi_spec_dst не равно нулю, то ipi_spec_dst будет использован как локальный адрес источника при просмотре таблицы маршрутизации и для установки IP-параметров маршрутизации от источника. Если значение ipi_ifindex не равно нулю, то при поиске в таблице маршрутизации вместо значения ipi_spec_dst используется первичный локальный адрес интерфейса с указанным индексом.

IP_RECVERR (начиная с Linux 2.2)

Делает передачу сообщений об ошибках более надёжной. Если этот параметр установлен для дейтаграмного сокета, то все возникающие ошибки будут поставлены в очередь ошибок, свою для каждого сокета. Для получения ошибки при операции с сокетом пользователь может воспользоваться вызовом recvmsg(2) с установленным флагом MSG_ERRQUEUE. Структура sock_extended_err, описывающая ошибку, будет передана в вспомогательном сообщении с типом IP_RECVERR и уровнем IPPROTO_IP. Этот параметр полезен для надежной обработки ошибок для сокетов без установления соединения. В пакете с ошибкой из очереди ошибок, также содержится порция полученных данных.

Вспомогательное сообщение IP_RECVERR содержит структуру sock_extended_err:

```
#define SO_EE_ORIGIN_NONE    0
#define SO_EE_ORIGIN_LOCAL   1
#define SO_EE_ORIGIN_ICMP    2
#define SO_EE_ORIGIN_ICMP6   3
struct sock_extended_err {

    uint32_t ee_errno;   /* номер ошибки */

    uint8_t  ee_origin;  /* где возникла ошибка */

    uint8_t  ee_type;    /* тип */

    uint8_t  ee_code;    /* код */

    uint8_t  ee_pad;

    uint32_t ee_info;    /* дополнительная информация */

    uint32_t ee_data;    /* другие данные */

    /* Дальше могут следовать данные */
};
struct sockaddr *SO_EE_OFFENDER(struct sock_extended_err *);

```

В ee_errno содержится номер ошибки в очереди. В ee_origin содержится код источника ошибки. Значение остальных полей зависит от протокола. Макрос SO_EE_OFFENDER возвращает указатель на адрес сетевого объекта, в котором возникла ошибка, согласно указанному указателю на вспомогательное сообщение. Если адрес неизвестен, то поле sa_family структуры sockaddr содержит AF_UNSPEC, и остальные поля sockaddr не определены.

Для IP структура sock_extended_err используется следующим образом: значение поля ee_origin устанавливается в SO_EE_ORIGIN_ICMP, если ошибка получена из пакета ICMP, или в SO_EE_ORIGIN_LOCAL, если возникла локальная ошибка. Неизвестные значения следует игнорировать. Значения полей ee_type и ee_code устанавливаются исходя из значений полей типа и кода заголовка ICMP. При ошибках EMSGSIZE поле ee_info содержит обнаруженную величину MTU. Сообщение также содержит структуру sockaddr_in узла, вызвавшего ошибку, которая доступна через макрос SO_EE_OFFENDER. Если источник неизвестен, то поле sin_family адреса, возвращённого макросом SO_EE_OFFENDER, содержит значение AF_UNSPEC. Если ошибка возникла в сети, то все параметры IP (IP_OPTIONS, IP_TTL и т.д.), которые используются сокетом и содержатся в пакете с описанием ошибки, передаются в управляющих сообщениях. Данные пакета, вызвавшего ошибку, возвращаются как нормальные данные. Заметьте, что у TCP нет очереди ошибок; флаг MSG_ERRQUEUE нельзя использовать для сокетов типа SOCK_STREAM. Параметр IP_RECVERR допустим для TCP, но все ошибки возвращаются только через функцию сокета или через параметр SO_ERROR.

Для неструктурированных сокетов, параметром IP_RECVERR включается передача в приложение всех получаемых ошибок ICMP, иначе сообщается только об ошибках в сокетах, ориентированных на соединение.

Этот параметр устанавливается или возвращается как логический флаг в виде целого числа. По умолчанию, параметр IP_RECVERR выключен.

IP_RECVOPTS (начиная с Linux 2.2)

Передает пользователю все входящие параметры IP с помощью управляющего сообщения IP_OPTIONS. Для локального узла заполняется заголовок маршрутизации и другие параметры. Не поддерживается сокетами типа SOCK_STREAM.

IP_RECVORIGDSTADDR (начиная с Linux 2.6.29)

Данный логический параметр включает вспомогательное сообщение IP_ORIGDSTADDR в recvmsg(2), в котором ядро возвращает первоначальный адрес назначения полученной дейтаграммы. Вспомогательное сообщение содержит структуру struct sockaddr_in.

IP_RECVTOS (начиная с Linux 2.2)

Если включён, то вместе с входящими пакетами передаётся вспомогательное сообщение IP_TOS. В нём содержится байт, в котором указано поле типа сервиса/приоритета из заголовка пакета. Ожидается логическое значение в виде целого числа.

IP_RECVTTL (начиная с Linux 2.2)

Если указан этот флаг, то передаётся управляющее сообщение IP_TTL с байтом значения поля времени существования из полученного пакета в виде 32-битного целого. Не поддерживается сокетами типа SOCK_STREAM.

IP_RETOPTS (начиная с Linux 2.2)

Идентичен параметру IP_RECVOPTS, но возвращает необработанные параметры, причём без заполненных временных меток и записи о маршрутизации до этой точки (hop).

IP_ROUTER_ALERT (начиная с Linux 2.2)

Передаёт этому сокету все пересылаемые (forwarded) пакеты с установленным параметром IP Router Alert. Этот параметр используется для «сырых» сокетов. Он может быть полезен, например, для служб RSVP, запущенных в пространстве пользователя. Перехваченные пакеты дальше ядром не пересылаются: ответственность за их отсылку лежит на пользователе. Связывание сокета игнорируется, так как пакеты фильтруются по протоколу. Ожидается логическое значение в виде целого числа.

IP_TOS (начиная с Linux 1.0)

Устанавливает или получает значение поля Type-Of-Service (TOS, тип сервиса) каждого IP-пакета, который отсылается с этого сокета. Это поле используется для указания приоритета пакета в сети. Значение TOS хранится в одном байте. Существует несколько стандартных флагов TOS: IPTOS_LOWDELAY — для минимизации задержки передаваемого трафика, IPTOS_THROUGHPUT — для оптимизации пропускной способности, IPTOS_RELIABILITY — для увеличения надёжности, IPTOS_MINCOST — при пересылки данных, для которых неважна скорость передачи. Может быть указано не более одного из этих значений TOS. Все другие биты являются недействительными и должны быть обнулены. По умолчанию, Linux посылает дейтаграммы с IPTOS_LOWDELAY первыми, но точное поведение зависит от настроенного порядка очередности (queueing discipline). Для установки некоторых высокоприоритетных типов сервиса могут потребоваться права суперпользователя (мандат CAP_NET_ADMIN).

IP_TRANSPARENT (начиная с Linux 2.6.24)

Установка этого логического параметра включает прозрачное проксирование на заданный сокет. Данный параметр сокета позволяет вызвавшему приложению привязаться к нелокальному IP-адресу и работать клиентом и сервером с внешним адресом как с локальной конечной точкой. ЗАМЕЧАНИЕ: требуется настройка маршрутизации пакетов для внешнего адреса через TProxy (то есть, системы, на которой находится приложение, применяющее параметр сокета IP_TRANSPARENT). Для установки данного параметра сокета требуются права суперпользователя (мандат CAP_NET_ADMIN).

Также, для установки данного параметра на перенаправляемый сокет требуется перенаправление TProxy с помощью цели TPROXY в iptables.

IP_TTL (начиная с Linux 1.0)

Устанавливает или получает текущее значение поля времени существования (time to live), которое указывается в каждом пакете, отсылаемом с этого сокета.

IP_UNBLOCK_SOURCE (начиная с Linux 2.4.22 / 2.5.68)

Разблокировать ранее заблокированный многоадресный источник. Возвращает EADDRNOTAVAIL, если указанный источник не заблокирован.

Аргументом является структура ip_mreq_source, описанная в разделе о IP_ADD_SOURCE_MEMBERSHIP.

### Интерфейсы в /proc
Настройку глобальных параметров протокола IP можно осуществлять через интерфейс /proc. Все параметры доступны посредством чтения или записи файлов из каталога /proc/sys/net/ipv4/. Для логических (Boolean) параметров значения указываются в виде целых чисел: ненулевое значение («истина») означает включает параметра, а нулевое значение («ложь») — выключение.

ip_always_defrag (Boolean; начиная с Linux 2.2.13)

[Появился в ядре версии 2.2.13; в ранних версиях это свойство контролировалось с помощью флага CONFIG_IP_ALWAYS_DEFRAG времени компиляции; данный параметр убран в 2.4.x]

Если этот флаг включён (не равен 0), то входящие фрагменты (части IP-пакетов, которые образуются, если некоторый узел, находящийся между отправителем и получателем, решает, что пакеты слишком велики и разделяет их на кусочки) будут снова собраны (дефрагментированны) перед дальнейшей обработкой, даже если они должны быть пересланы дальше.

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

Этот параметр включается автоматически при настройке маскарадинга или прозрачного проксирования.

ip_autoconfig (в Linux 2.2 по 2.6.17)

Не описан.

ip_default_ttl (integer; по умолчанию: 64; начиная с Linux 2.2)

Устанавливает значение time-to-live по умолчанию для исходящих пакетов. Это значение может быть изменено для каждого отдельного сокета с помощью параметра IP_TTL.

ip_dynaddr (Boolean; по умолчанию: выключен; начиная с Linux 2.0.31)

Включает динамическую адресацию сокета и подмену (masquerading) при изменении адреса интерфейса. Это полезно для интерфейсов коммутируемых соединений (dialup) с изменяющимися IP-адресами. Значение 0 означает не подменять, 1 включает подмену и 2 включает режим подробностей работы.

ip_forward (Boolean; по умолчанию: выключен; начиная с Linux 1.2)

Включает/выключает пересылку (forwarding) IP-пакетов. Пересылка IP также может быть включена для каждого интерфейса в отдельности.

ip_local_port_range (начиная с Linux 2.2)

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

- при вызове bind(2) в номере порта адреса сокета указан 0;

- Вызов listen(2) вызван для потокового сокета, который ещё не привязан;

- Вызов connect(2) вызван для сокета, который ещё не привязан;

- Вызов sendto(2) вызван для дейтаграмного сокета, который ещё не привязан.

Выделение эфемерных портов начинается с первого числа в ip_local_port_range и заканчивается вторым числом. Если диапазон эфемерных портов закончился, то соответствующий системный вызов вернёт ошибку (но смотрите ДЕФЕКТЫ).

Заметим, что диапазон портов в ip_local_port_range не должен конфликтовать с портами, используемыми для маскарадинг (хотя это проверяется). Также, произвольные значения могут вызвать проблемы с некоторыми пакетными фильтрами межсетевых экранов, которые делают предположения об используемых локальных портах. Первое число должно быть не менее 1024, или лучше более 4096, чтобы не пересекаться с всем известными портами и минимизировать проблемы с межсетевыми экранами.

ip_no_pmtu_disc (Boolean; по умолчанию: выключен; начиная с Linux 2.2)

Если включён, то, по умолчанию, не производится обнаружение значения MTU у маршрута для TCP сокетов. Обнаружение MTU маршрута может завершиться с ошибкой из-за встретившихся на пути неверно настроенных межсетевых экранов (которые отбрасывают все пакеты ICMP) или из-за неверно настроенных интерфейсов (например, соединение точка-точка, у которого оба конца не договорились о MTU). Лучше исправить встреченные на пути неисправные маршрутизаторы, чем глобально отключать обнаружение MTU маршрута, потому что это отключение приведёт к высокой нагрузке на сеть.

ip_nonlocal_bind (Boolean; по умолчанию: выключен; начиная с Linux 2.4)

Если установлен, то это позволяет процессам привязываться (bind(2)) к нелокальным IP-адресам, что полезно, но может привести к неработоспособности некоторых приложений.

ip6frag_time (integer; по умолчанию: 30)

Время в секундах, на которое фрагмент IPv6 остаётся в памяти.

ip6frag_secret_interval (integer; по умолчанию: 600)

Интервал регенерации (в секундах) контрольной суммы секрета (hash secret) (или время существования контрольной суммы секрета) фрагментов IPv6.

ipfrag_high_thresh (integer), ipfrag_low_thresh (integer)

Если количество фрагментов IP, стоящих в очереди, достигает значения ipfrag_high_thresh, то очередь укорачивается до значения ipfrag_low_thresh. Содержит целое число, означающее количество байт.

neigh/*

Смотрите в arp(7).

### Вызовы ioctl
Все вызовы ioctl, описанные в socket(7), применимы к ip.

Вызовы ioctl для настройки общих параметров устройств описаны в netdevice(7).

## ОШИБКИ
EACCES

Пользователь попытался выполнить действие, не имея на это необходимых полномочий. Примеры таких действий: посылка пакета по широковещательному адресу без предварительной установки флага SO_BROADCAST; посылка пакета по запрещённому маршруту; изменение настроек межсетевого экрана не имея прав суперпользователя (мандата CAP_NET_ADMIN); связывание сокета с зарезервированным портом, не имея прав суперпользователя (мандата CAP_NET_BIND_SERVICE).

EADDRINUSE

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

EADDRNOTAVAIL

Был запрошен несуществующий интерфейс или запрошенный исходящий адрес не является локальным.

EAGAIN

Действие над неблокирующим сокетом привело бы к его блокировке.

EALREADY

Операция соединения на неблокирующем сокете уже находится в процессе выполнения.

ECONNABORTED

Соединение закрыто во время accept(2).

EHOSTUNREACH

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

EINVAL

Передан недопустимый аргумент. При операциях отправки эта ошибка может возникнуть из-за передачи по маршруту чёрная дыра (blackhole).

EISCONN

Вызов connect(2) запущен для сокета, уже установившего соединение.

EMSGSIZE

Дейтаграмма больше значения MTU на маршруте, и она не может быть фрагментирована.

ENOBUFS, ENOMEM

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

ENOENT

Для сокета вызван SIOCGSTAMP, но он ещё не получил ни одного пакета.

ENOPKG

Не настроена подсистема ядра.

ENOPROTOOPT и EOPNOTSUPP

Передан недопустимый параметр сокета.

ENOTCONN

Операция определена только для сокета, установившего соединение, а этот сокет не соединён.

EPERM

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

EPIPE

Соединение неожиданно закрылось или завершено (shut down) другой стороной.

ESOCKTNOSUPPORT

Сокет не настроен или запрошен неизвестный тип сокета.

Протоколами более высокого уровня могут генерироваться другие ошибки; смотрите tcp(7), raw(7), udp(7) и socket(7).

## ЗАМЕЧАНИЯ
Значения IP_FREEBIND, IP_MSFILTER, IP_MTU, IP_MTU_DISCOVER, IP_RECVORIGDSTADDR, IP_PKTINFO, IP_RECVERR, IP_ROUTER_ALERT и IP_TRANSPARENT есть только в Linux.

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

Для определения адреса назначения и интерфейса полученных дейтаграмм в некоторые реализациях сокетов BSD введены параметры сокетов IP_RCVDSTADDR и IP_RECVIF. В Linux для этой цели есть общий параметр IP_PKTINFO.

В некоторых реализациях сокетов BSD также есть параметр IP_RECVTTL, но вспомогательное сообщение с типом IP_RECVTTL передаётся с входным пакетом. В этом отличие от параметра IP_TTL, используемого в Linux.

Использование уровня параметров сокета SOL_IP непереносимо — в BSD-стеках используется уровень IPPROTO_IP.

Значение INADDR_ANY (0.0.0.0) и INADDR_BROADCAST (255.255.255.255) указываются с нейтральным порядком байт. Это означает, что htonl(3) на них не действует.

### Совместимость
Для совместимости с Linux 2.0 устаревший синтаксис socket(AF_INET, SOCK_PACKET, protocol) всё ещё поддерживается для открытия сокетов типа packet(7). Такое использование не поощряется и должно быть заменено на socket(AF_PACKET, SOCK_RAW, protocol). Основное различие между ними в новой адресной структуре sockaddr_ll (вместо старой структуры sockaddr_pkt), хранящей информацию обобщённого уровня соединения.

## ДЕФЕКТЫ
Слишком много противоречий в значениях ошибок.

Ошибка, используемая при диагностике исчерпания диапазона эфемерных портов, отличается в различных системных вызовах (connect(2), bind(2), listen(2), sendto(2)), из-за чего эфемерные порты могут быть назначены.

Не описаны ioctl для настройки специальных параметров IP для интерфейса и таблиц ARP.

Получение исходного адреса назначения в msg_name с помощью MSG_ERRQUEUE вызовом recvmsg(2) не работает в некоторых ядрах 2.2.

## СМОТРИТЕ ТАКЖЕ
recvmsg(2), sendmsg(2), byteorder(3), ipfw(4), capabilities(7), icmp(7), ipv6(7), netlink(7), raw(7), socket(7), tcp(7), udp(7), ip(8)

Первоначальная спецификация IP описана в RFC 791. В RFC 1122 определены требования для узлов IPv4. В RFC 1812 определены требования для маршрутизаторов IPv4.


title: ipc_namespaces(7)

summary: обзор пространств имён IPC в Linux

text:
# ipc_namespaces(7)

## ИМЯ
namespaces - обзор пространств имён IPC в Linux

## ОПИСАНИЕ
Пространства имён IPC изолируют определённые ресурсы IPC, а именно IPC-объекты System V (смотрите sysvipc(7)) и (начиная с Linux 2.6.30) очереди сообщений POSIX (смотрите mq_overview(7)). Общая характеристика этих механизмов IPC в том, что объекты IPC распознаются механизмами не как пути файловой системы.

Каждое пространство имён IPC имеет свой набор идентификаторов System V IPC и свою файловую систему для очереди сообщений POSIX. Объекты, созданные в пространстве имён IPC, видимы всем другим процессам, которые являются членами этого пространства имён, и невидимы процессам из других пространств имён IPC.

Следующие интерфейсы /proc отличаются в каждом пространстве имён IPC:

- Интерфейсы очереди сообщений POSIX в /proc/sys/fs/mqueue.

- IPC-интерфейсы System V в /proc/sys/kernel, а именно: msgmax, msgmnb, msgmni, sem, shmall, shmmax, shmmni и shm_rmid_forced.

- IPC-интерфейсы System V в /proc/sysvipc.

При уничтожении пространства имён IPC (т. е., когда завершается последний процесс из этого пространства имён), все объекты IPC из пространства имён автоматически уничтожаются.

Для использования пространств имён IPC требуется, чтобы ядро было собрано с параметром CONFIG_IPC_NS.

## СМОТРИТЕ ТАКЖЕ
nsenter(1), unshare(1), clone(2), setns(2), unshare(2), mq_overview(7), namespaces(7), sysvipc(7)


title: ipv6(7)

summary: реализация протокола IPv6 в Linux

text:
# ipv6(7)

## ИМЯ
ipv6 - реализация протокола IPv6 в Linux

## ОБЗОР
\#include <sys/socket.h>

\#include <netinet/in.h>

tcp6_socket = socket(AF_INET6, SOCK_STREAM, 0);

raw6_socket = socket(AF_INET6, SOCK_RAW, protocol);

udp6_socket = socket(AF_INET6, SOCK_DGRAM, protocol);

## ОПИСАНИЕ
В Linux 2.2 реализован протокол Интернета версии 6. Эта справочная страница содержит описание основного программного интерфейса IPv6, который реализован в ядре Linux и в glibc 2.1. Программный интерфейс основан на интерфейсе сокетов BSD; смотрите socket(7).

Программный интерфейс IPv6, по большей части, совместим с IPv4 (смотрите ip(7)). В этой справочной странице описаны только различия между ними.

Чтобы привязать сокет AF_INET6 к любому процессу нужно скопировать локальный адрес из переменной in6addr_any, имеющей тип in6_addr. При статической инициализации также может быть использован макрос IN6ADDR_ANY_INIT, который раскрывается в константное выражение. В обоих значениях используется сетевой порядок байт.

Адрес устройства обратной петли IPv6 (::1) доступен в глобальной переменной in6addr_loopback. Для инициализации нужно использовать IN6ADDR_LOOPBACK_INIT.

Соединения IPv4 могут обрабатываться программным интерфейсом v6 с помощью адресного типа v4-преобразованный-в-v6; то есть программе необходимо поддерживать только данный тип программного интерфейса для работы с обоими протоколами. Прозрачная работа с адресами реализована в функциях библиотеки Си.

IPv4 и IPv6 совместно используют локальное портовое пространство. При установлении соединения IPv4 или приёма пакета на сокете IPv6, адрес его источника отобразится в v6, и в дальнейшем он будет отображаться как v6.

### Формат адреса

```
struct sockaddr_in6 {

    sa_family_t     sin6_family;   /* AF_INET6 */

    in_port_t       sin6_port;     /* номер порта */

    uint32_t        sin6_flowinfo; /* информация о потоке IPv6 */

    struct in6_addr sin6_addr;     /* адрес IPv6 */

    uint32_t        sin6_scope_id; /* ID области (новое в 2.4) */
};
struct in6_addr {

    unsigned char   s6_addr[16];   /* адрес IPv6 */
};
```

Значение sin6_family всегда устанавливается в AF_INET6; в sin6_port указывается порт протокола (смотрите sin_port в ip(7)); в sin6_flowinfo указывается идентификатор потока IPv6; в sin6_addr указывается 128-битный адрес IPv6. Значением sin6_scope_id является идентификатор, зависящий от области адреса. Это новое поле, появившееся в версии Linux 2.4. Linux поддерживает его только для адресов локальной связи (link local); в этом случае sin6_scope_id содержит индекс интерфейса (смотрите netdevice(7)).

IPv6 поддерживает несколько типов адресов: однозначные (unicast) — для адресации одного узла, многоадресные (multicast) — для адресации группы узлов, anycast — для адресации ближайшего члена группы узлов (не реализовано в Linux), IPv4-on-IPv6 — для адресации узла IPv4, и несколько других зарезервированных типов адресов.

Адрес IPv6 представляет собой группу из 8 4-разрядных шестнадцатеричных чисел, разделённых двоеточием «:». Два двоеточия «::» обозначают строку 0 бит. Специальные адреса: ::1 (для устройства обратной петли) и FFFF::<адрес IPv4> — для IPv4-преобразованного-в-IPv6.

В IPv6 используется единое с IPv4 пространство портов.

### Параметры сокета
IPv6 поддерживает некоторые параметры сокета, относящиеся к протоколу, которые могут быть установлены с помощью setsockopt(2) и прочитаны с помощью getsockopt(2). Значением уровня (level) параметров сокета для IPv6 является IPPROTO_IPV6. Логический флаг в виде целого числа со значением 0 означает «ложь», другие значения — «истина».

IPV6_ADDRFORM

Преобразует сокет AF_INET6 в сокет другого семейства адресов. На данный момент поддерживается только AF_INET. Разрешено только для сокетов IPv6, которые подсоединены и привязаны к адресам v4-преобразованные-в-v6. В аргументе задаётся указатель на целое со значением AF_INET. Это полезно для передачи v4-преобразованных сокетов в виде дескрипторов файлов программам, которые не понимают программного интерфейса IPv6.

IPV6_ADD_MEMBERSHIP, IPV6_DROP_MEMBERSHIP

Определяет членство в многоадресных (multicast) группах. Аргументом является указатель на struct ipv6_mreq.

IPV6_MTU

getsockopt(): Возвращает известное в данный момент значение MTU маршрута текущего сокета. Только для подключённых сокетов. Возвращается целое число.

setsockopt(): Устанавливает MTU, который должен использоваться для сокета. MTU ограничивается значением MTU устройства или MTU пути, если включено определение пути MTU. Аргументом является указатель на целое.

IPV6_MTU_DISCOVER

Управляет определением пути MTU для сокета. Смотрите описание IP_MTU_DISCOVER в ip(7).

IPV6_MULTICAST_HOPS

Определяет лимит многоадресных пересылок (hop) для сокета. Аргументом является указатель на целое число. Значение -1 означает использование маршрута по умолчанию, в противном случае значение должно быть в диапазоне от 0 до 255.

IPV6_MULTICAST_IF

Назначает устройство для исходящих многоадресных пакетов для сокета. Это разрешено только для сокетов SOCK_DGRAM и SOCK_RAW. Аргументом является указатель на индекс интерфейса (смотрите netdevice(7)) в виде целого числа.

IPV6_MULTICAST_LOOP

Определяет, видит ли сокет многоадресные пакеты, которые сам и посылал. Аргументом является указатель на логическое значение.

IPV6_RECVPKTINFO (начиная с Linux 2.6.14)

Задаёт отправку управляющего сообщения IPV6_PKTINFO для входящих дейтаграмм. Такие управляющие сообщения содержат структуру struct in6_pktinfo, описанную в RFC 3542. Разрешено только для сокетов SOCK_DGRAM или SOCK_RAW. Аргументом является указатель на логическое значение в виде целого числа.

IPV6_RTHDR, IPV6_AUTHHDR, IPV6_DSTOPTS, IPV6_HOPOPTS, IPV6_FLOWINFO,

IPV6_HOPLIMIT Задают отправку управляющих сообщений для входящих датаграмм, содержащих заголовки расширения из принятых пакетов. IPV6_RTHDR доставляет заголовок маршрутизации, IPV6_AUTHHDR доставляет заголовок аутентификации, IPV6_DSTOPTS доставляет параметры назначения, IPV6_HOPOPTS доставляет параметры пересылок (hop), IPV6_FLOWINFO доставляет целое, содержащее ID потока, IPV6_HOPLIMIT доставляет целое, содержащее счётчик пересылок пакета. Управляющие сообщения имеют тот же тип, что и параметры сокета. Все эти параметры заголовка могут также устанавливаться для исходящих пакетов посылкой определённого управляющего сообщения в управляющий буфер sendmsg(2). Разрешено только для сокетов SOCK_DGRAM или SOCK_RAW. Аргументом является указатель на логическое значение.

IPV6_RECVERR

Управляет получением асинхронных параметров ошибки. Смотрите описание IP_RECVERR в ip(7). Аргументом является указатель на логическое значение.

IPV6_ROUTER_ALERT

Передаёт все пересланные пакеты, содержащие предупреждающий параметр hop-by-hop маршрутизатора в сокет. Разрешено только для сокетов SOCK_RAW. Выявленные пакеты не пересылаются ядром, пользователь должен отправить заново самостоятельно. Аргументом является указатель на целое. Положительное число означает перехват значения предупреждающего параметра маршрутизатора. Пакеты, содержащие предупреждающий параметр маршрутизатора с таким значением поля, будут доставлены в сокет. Отрицательное значение отключает доставку пакетов с предупреждающим параметром маршрутизатора в сокет.

IPV6_UNICAST_HOPS

Определяет лимит однозначных (unicast) пересылок (hop) для сокета. Аргументом является указатель на целое число. Значение -1 означает использование маршрута по умолчанию, в противном случае его значение должно быть в диапазоне от 0 до 255.

IPV6_V6ONLY (начиная с Linux 2.4.21 и 2.6)

Если этот флаг установлен (не равен 0), то сокет отправляет и принимает только пакеты IPv6. В этом случае приложение IPv4 и IPv6 может привязать один порт за раз.

Если этот флаг сброшен (равен 0), то сокет можно использовать для отправки и приёма пакетов с и на адрес IPv6 или адрес IPv4-преобразованный-в-IPv6.

Аргументом является указатель на логическое значение в виде целого числа.

Значение этого флага по умолчанию определяется из содержимого файла /proc/sys/net/ipv6/bindv6only. По умолчанию значение в файле 0.

## ОШИБКИ
ENODEV

Пользователь пытался выполнить bind(2) на адрес локальной связи IPv6, но sin6_scope_id в переданной структуре sockaddr_in6 содержит некорректный индекс интерфейса.

## ВЕРСИИ
В Linux 2.4 сломана двоичная совместимость sockaddr_in6 у 64-битных узлов из-за изменения выравнивания in6_addr и добавления дополнительного поля sin6_scope_id. Интерфейс ядра остался совместимым, но программа, включающая sockaddr_in6 или in6_addr в другие структуры, уже может не быть совместимой. Это не является проблемой для 32-битных узлов, например с архитектурой i386.

Поле sin6_flowinfo является нововведением в Linux 2.4. Оно прозрачно передаётся/считывается ядром в длине переданного адреса. Некоторые программы, которые передают более длинный буфер адреса и затем проверяют длину исходящего адреса, могут перестать работать.

## ЗАМЕЧАНИЯ
Структура sockaddr_in6 по размеру больше, чем обычная sockaddr. Программы, которые допускают, что все типы адреса могут без проблем сохраняться в struct sockaddr, нужно изменить использовав вместо неё struct sockaddr_storage.

Параметры сокета SOL_IP, SOL_IPV6, SOL_ICMPV6 и другие SOL_* являются непереносимыми вариантами IPPROTO_*. Смотрите также ip(7).

## ДЕФЕКТЫ
Расширенный программный интерфейс IPv6, описанный в RFC 2292, к настоящему времени реализован частично; хотя ядро версии 2.2 имеет почти полную поддержку параметров приёма, макросы для генерации параметров IPv6 в glibc 2.1 отсутствуют.

Поддержка IPSec для заголовков EH и АХ отсутствует.

Описание управления потоком на основе меток (label) не завершено и здесь не описано.

Эта справочная страница не полна.

## СМОТРИТЕ ТАКЖЕ
cmsg(3), ip(7)

RFC 2553: IPv6 BASIC API; Linux пытается быть совместимым с этим стандартом. RFC 2460: спецификация IPv6.


title: iso_8859-1(7)

summary: набор символов ISO 8859\-1, представленный восьмеричным,

text:
# iso_8859-1(7)

## ИМЯ
iso_8859-1 - набор символов ISO 8859-1, представленный восьмеричным, десятичным и шестнадцатеричным кодом

## ОПИСАНИЕ
Стандарт ISO 8819 включает в себя несколько 8-битных расширений набора символов ASCII (также известных как ISO 646-IRV). В ISO 8859-1 кодируются символы, используемые в многих юго-западных европейских языках.

### алфавиты ISO 8859
Полный набор алфавитов ISO 8859 включает в себя:

ISO 8859-1

западноевропейские языки (Latin-1)

ISO 8859-2

центрально- и восточноевропейские языки (Latin-2)

ISO 8859-3

языки юго-восточной Европы и другие языки (Latin-3)

ISO 8859-4

скандинавские/балтийские языки (Latin-4)

ISO 8859-5

латинский/кириллица

ISO 8859-6

латинский/арабский

ISO 8859-7

латинский/греческий

ISO 8859-8

латинский/иврит

ISO 8859-9

вариант Latin-1 для турецкого алфавита (Latin-5)

ISO 8859-10

саамский/скандинавский/эскимосский языки (Latin-6)

ISO 8859-11

латинский/тайский

ISO 8859-13

балтийские языки (Latin-7)

ISO 8859-14

кельтский (Latin-8)

ISO 8859-15

западноевропейские языки (Latin-9)

ISO 8859-16

румынский (Latin-10)

### символы ISO 8859-1
В следующей таблице показаны символы из набора ISO 8859-1, являющиеся печатными и отсутствующие в справочной странице ascii(7).

Вос

Дес

Шес

Симв

Описание

240

160

A0

НЕРАЗРЫВНЫЙ ПРОБЕЛ

241

161

A1

¡

ПЕРЕВЁРНУТЫЙ ВОСКЛИЦАТЕЛЬНЫЙ ЗНАК

242

162

A2

¢

ЗНАК ЦЕНТА

243

163

A3

£

ЗНАК ФУНТА

244

164

A4

¤

СИМВОЛ ВАЛЮТЫ

245

165

A5

¥

ЗНАК ИЕНЫ

246

166

A6

¦

ПРЕРЫВЕСТАЯ ВЕРТИКАЛЬНАЯ ЧЕРТА

247

167

A7

§

СИМВОЛ ПАРАГРАФА

250

168

A8

¨

УМЛЯУТ

251

169

A9

©

ЗНАК ОХРАНЫ АВТОРСКОГО ПРАВА

252

170

AA

ª

ПОРЯДКОВЫЙ ИНДИКАТОР (ЖЕНСКИЙ РОД)

253

171

AB

«

ОТКРЫВАЮЩАЯ ЛЕВАЯ КАВЫЧКА «ЁЛОЧКА»

254

172

AC

¬

ЗНАК ОТРИЦАНИЯ

255

173

AD

МЯГКИЙ ПЕРЕНОС

256

174

AE

®

ЗАРЕГИСТРИРОВАННЫЙ ТОВАРНЫЙ ЗНАК

257

175

AF

¯

МАКРОН

260

176

B0

°

ЗНАК ГРАДУСА

261

177

B1

±

ЗНАК ПЛЮС-МИНУС

262

178

B2

²

ЦИФРА ДВА ВВЕРХУ МЕЛКИМ ШРИФТОМ

263

179

B3

³

ЦИФРА ТРИ ВВЕРХУ МЕЛКИМ ШРИФТОМ

264

180

B4

´

ОСТРОЕ УДАРЕНИЕ

265

181

B5

µ

ЗНАК МИКРО

266

182

B6

¶

ЗНАК АБЗАЦА

267

183

B7

·

ТОЧКА В ЦЕНТРЕ

270

184

B8

¸

СЕДИЛЬ

271

185

B9

¹

ЦИФРА ОДИН ВВЕРХУ МЕЛКИМ ШРИФТОМ

272

186

BA

º

ПОРЯДКОВЫЙ ИНДИКАТОР (МУЖСКОЙ РОД)

273

187

BB

»

ЗАКРЫВАЮЩАЯ КАВЫЧКА «ЁЛОЧКА»

274

188

BC

¼

ДРОБЬ ОДНА ЧЕТВЁРТАЯ

275

189

BD

½

ДРОБЬ ОДНА ВТОРАЯ

276

190

BE

¾

ДРОБЬ ТРИ ЧЕТВЁРТЫХ

277

191

BF

¿

ПЕРЕВЁРНУТЫЙ ВОПРОСИТЕЛЬНЫЙ ЗНАК

300

192

C0

À

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С ГРАВИСОМ

301

193

C1

Á

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С АКУТОМ

302

194

C2

Â

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С ШЛЯПОЙ

303

195

C3

Ã

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С ТИЛЬДОЙ

304

196

C4

Ä

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С УМЛЯУТОМ

305

197

C5

Å

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С КРУЖОЧКОМ СВЕРХУ

306

198

C6

Æ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «AE»

307

199

C7

Ç

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «C» С СЕДИЛЬЮ

310

200

C8

È

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «E» С ГРАВИСОМ

311

201

C9

É

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «E» C АКУТОМ

312

202

CA

Ê

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «E» С ШЛЯПОЙ

313

203

CB

Ë

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «E» С УМЛЯУТОМ

314

204

CC

Ì

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «I» С ГРАВИСОМ

315

205

CD

Í

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «I» С АКУТОМ

316

206

CE

Î

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «I» С ШЛЯПОЙ

317

207

CF

Ï

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «I» С УМЛЯУТОМ

320

208

D0

Ð

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «ЕТХ»

321

209

D1

Ñ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «N» С ТИЛЬДОЙ

322

210

D2

Ò

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» С ГРАВИСОМ

323

211

D3

Ó

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» С АКУТОМ

324

212

D4

Ô

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» С ШЛЯПОЙ

325

213

D5

Õ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» С ТИЛЬДОЙ

326

214

D6

Ö

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» С УМЛЯУТОМ

327

215

D7

×

ЗНАК УМНОЖЕНИЯ

330

216

D8

Ø

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» СО ШТРИХОМ

331

217

D9

Ù

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «U» С ГРАВИСОМ

332

218

DA

Ú

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «U» С АКУТОМ

333

219

DB

Û

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «U» С ШЛЯПОЙ

334

220

DC

Ü

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «U» С УМЛЯУТОМ

335

221

DD

Ý

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «Y» С АКУТОМ

336

222

DE

Þ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «ТОРН»

337

223

DF

ß

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА ОСТРАЯ «S»

340

224

E0

à

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С ГРАВИСОМ

341

225

E1

á

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С АКУТОМ

342

226

E2

â

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С ШЛЯПОЙ

343

227

E3

ã

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С ТИЛЬДОЙ

344

228

E4

ä

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С УМЛЯУТОМ

345

229

E5

å

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С КРУЖОЧКОМ СВЕРХУ

346

230

E6

æ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «AE»

347

231

E7

ç

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «C» С СЕДИЛЬЮ

350

232

E8

è

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «E» С ГРАВИСОМ

351

233

E9

é

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «E» С АКУТОМ

352

234

EA

ê

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «E» С ШЛЯПОЙ

353

235

EB

ë

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «E» С УМЛЯУТОМ

354

236

EC

ì

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «I» С ГРАВИСОМ

355

237

ED

í

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «I» С АКУТОМ

356

238

EE

î

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «I» С ШЛЯПОЙ

357

239

EF

ï

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «I» С УМЛЯУТОМ

360

240

F0

ð

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «ЕТХ»

361

241

F1

ñ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «N» С ТИЛЬДОЙ

362

242

F2

ò

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» С ГРАВИСОМ

363

243

F3

ó

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» С АКУТОМ

364

244

F4

ô

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» С ШЛЯПОЙ

365

245

F5

õ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» С ТИЛЬДОЙ

366

246

F6

ö

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» С УМЛЯУТОМ

367

247

F7

÷

ЗНАК ДЕЛЕНИЯ

370

248

F8

ø

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» СО ШТРИХОМ

371

249

F9

ù

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «U» С ГРАВИСОМ

372

250

FA

ú

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «U» С АКУТОМ

373

251

FB

û

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «U» С ШЛЯПОЙ

374

252

FC

ü

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «U» С УМЛЯУТОМ

375

253

FD

ý

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «Y» С АКУТОМ

376

254

FE

þ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «ТОРН»

377

255

FF

ÿ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «Y» С УМЛЯУТОМ

## ЗАМЕЧАНИЯ
ISO 8859-1 также известна как Latin-1.

## СМОТРИТЕ ТАКЖЕ
ascii(7), charsets(7), cp1252(7), iso_8859-15(7), utf-8(7)


title: iso_8859-10(7)

summary: набор символов ISO 8859\-10, представленный восьмеричным,

text:
# iso_8859-10(7)

## ИМЯ
iso_8859-10 - набор символов ISO 8859-10, представленный восьмеричным, десятичным и шестнадцатеричным кодом

## ОПИСАНИЕ
Стандарт ISO 8859 включает в себя несколько 8-битных расширений набора символов ASCII (также известной как ISO 646-IRV). В ISO 8859-10 кодируются символы, используемые в скандинавских языках.

### алфавиты ISO 8859
Полный набор алфавитов ISO 8859 включает в себя:

ISO 8859-1

западноевропейские языки (Latin-1)

ISO 8859-2

центрально- и восточноевропейские языки (Latin-2)

ISO 8859-3

языки юго-восточной Европы и другие языки (Latin-3)

ISO 8859-4

скандинавские/балтийские языки (Latin-4)

ISO 8859-5

латинский/кириллица

ISO 8859-6

латинский/арабский

ISO 8859-7

латинский/греческий

ISO 8859-8

латинский/иврит

ISO 8859-9

вариант Latin-1 для турецкого алфавита (Latin-5)

ISO 8859-10

саамский/скандинавский/эскимосский языки (Latin-6)

ISO 8859-11

латинский/тайский

ISO 8859-13

балтийские языки (Latin-7)

ISO 8859-14

кельтский (Latin-8)

ISO 8859-15

западноевропейские языки (Latin-9)

ISO 8859-16

румынский (Latin-10)

### символы ISO 8859-10
В следующей таблице показаны символы из набора ISO 8859-10, являющиеся печатными и отсутствующие в справочной странице ascii(7).

Вос

Дес

Шес

Симв

Описание

240

160

A0

НЕРАЗРЫВНЫЙ ПРОБЕЛ

241

161

A1

Ą

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С ОГОНЭКОМ

242

162

A2

Ē

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «E» С МАКРОНОМ

243

163

A3

Ģ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «G» С СЕДИЛЬЮ

244

164

A4

Ī

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «I» С МАКРОНОМ

245

165

A5

Ĩ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «I» С ТИЛЬДОЙ

246

166

A6

Ķ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «K» С СЕДИЛЬЮ

247

167

A7

§

СИМВОЛ ПАРАГРАФА

250

168

A8

Ļ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «L» С СЕДИЛЬЮ

251

169

A9

Đ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «D» СО ШТРИХОМ

252

170

AA

Š

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «S» С ГАЛОЧКОЙ

253

171

AB

Ŧ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «T» СО ШТРИХОМ

254

172

AC

Ž

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «Z» С ГАЛОЧКОЙ

255

173

AD

МЯГКИЙ ПЕРЕНОС

256

174

AE

Ū

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «U» С МАКРОНОМ

257

175

AF

Ŋ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «ENG»

260

176

B0

°

ЗНАК ГРАДУСА

261

177

B1

ą

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С ОГОНЭКОМ

262

178

B2

ē

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «E» С МАКРОНОМ

263

179

B3

ģ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «G» С СЕДИЛЬЮ

264

180

B4

ī

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «I» С МАКРОНОМ

265

181

B5

ĩ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «I» С ТИЛЬДОЙ

266

182

B6

ķ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «K» С СЕДИЛЬЮ

267

183

B7

·

ТОЧКА В ЦЕНТРЕ

270

184

B8

ļ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «L» С СЕДИЛЬЮ

271

185

B9

đ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «D» СО ШТРИХОМ

272

186

BA

š

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «S» С ГАЛОЧКОЙ

273

187

BB

ŧ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «T» СО ШТРИХОМ

274

188

BC

ž

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «Z» С ГАЛОЧКОЙ

275

189

BD

―

ГОРИЗОНТАЛЬНАЯ ЛИНИЯ

276

190

BE

ū

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «U» С МАКРОНОМ

277

191

BF

ŋ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «ENG»

300

192

C0

Ā

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С МАКРОНОМ

301

193

C1

Á

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С АКУТОМ

302

194

C2

Â

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С ШЛЯПОЙ

303

195

C3

Ã

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С ТИЛЬДОЙ

304

196

C4

Ä

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С УМЛЯУТОМ

305

197

C5

Å

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «A» С КРУЖОЧКОМ СВЕРХУ

306

198

C6

Æ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «AE»

307

199

C7

Į

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «I» С ОГОНЭКОМ

310

200

C8

Č

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «C» С ГАЛОЧКОЙ

311

201

C9

É

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «E» C АКУТОМ

312

202

CA

Ę

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «E» С ОГОНЭКОМ

312

202

CB

Ë

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «E» С УМЛЯУТОМ

314

204

CC

Ė

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «E» С ТОЧКОЙ СВЕРХУ

315

205

CD

Í

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «I» С АКУТОМ

316

206

CE

Î

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «I» С ШЛЯПОЙ

317

207

CF

Ï

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «I» С УМЛЯУТОМ

320

208

D0

Ð

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «ЕТХ»

321

209

D1

Ņ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «N» С СЕДИЛЬЮ

322

210

D2

Ō

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» С МАКРОНОМ

323

211

D3

Ó

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» С АКУТОМ

324

212

D4

Ô

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» С ШЛЯПОЙ

325

213

D5

Õ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» С ТИЛЬДОЙ

326

214

D6

Ö

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» С УМЛЯУТОМ

327

215

D7

Ũ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «U» С ТИЛЬДОЙ

330

216

D8

Ø

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «O» СО ШТРИХОМ

331

217

D9

Ų

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «U» С ОГОНЭКОМ

332

218

DA

Ú

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «U» С АКУТОМ

333

219

DB

Û

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «U» С ШЛЯПОЙ

334

220

DC

Ü

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «U» С УМЛЯУТОМ

335

221

DD

Ý

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «Y» С АКУТОМ

336

222

DE

Þ

ЛАТИНСКАЯ ЗАГЛАВНАЯ БУКВА «ТОРН»

337

223

DF

ß

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА ОСТРАЯ «S»

340

224

E0

ā

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С МАКРОНОМ

341

225

E1

á

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С АКУТОМ

342

226

E2

â

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С ШЛЯПОЙ

343

227

E3

ã

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С ТИЛЬДОЙ

344

228

E4

ä

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С УМЛЯУТОМ

345

229

E5

å

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «A» С КРУЖОЧКОМ СВЕРХУ

346

230

E6

æ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «AE»

347

231

E7

į

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «I» С ОГОНЭКОМ

350

232

E8

č

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «C» С ГАЛОЧКОЙ

351

233

E9

é

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «E» С АКУТОМ

352

234

EA

ę

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «E» С ОГОНЭКОМ

353

235

EB

ë

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «E» С УМЛЯУТОМ

354

236

EC

ė

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «E» С ТОЧКОЙ СВЕРХУ

355

237

ED

í

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «I» С АКУТОМ

356

238

EE

î

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «I» С ШЛЯПОЙ

357

239

EF

ï

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «I» С УМЛЯУТОМ

360

240

F0

ð

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «ЕТХ»

361

241

F1

ņ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «N» С СЕДИЛЬЮ

362

242

F2

ō

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» С МАКРОНОМ

363

243

F3

ó

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» С АКУТОМ

364

244

F4

ô

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» С ШЛЯПОЙ

365

245

F5

õ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» С ТИЛЬДОЙ

366

246

F6

ö

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» С УМЛЯУТОМ

367

247

F7

ũ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «U» С ТИЛЬДОЙ

370

248

F8

ø

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «O» СО ШТРИХОМ

371

249

F9

ų

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «U» С ОГОНЭКОМ

372

250

FA

ú

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «U» С АКУТОМ

373

251

FB

û

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «U» С ШЛЯПОЙ

374

252

FC

ü

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «U» С УМЛЯУТОМ

375

253

FD

ý

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «Y» С АКУТОМ

376

254

FE

þ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «ТОРН»

377

255

FF

ĸ

ЛАТИНСКАЯ СТРОЧНАЯ БУКВА «КРА» (Гренландский язык)

## ЗАМЕЧАНИЯ
ISO 8859-10 также известна как Latin-6.

## СМОТРИТЕ ТАКЖЕ
ascii(7), charsets(7), utf-8(7)


title: iso_8859-11(7)

summary: набор символов ISO 8859\-11, представленный восьмеричным,

text:
# iso_8859-11(7)

## ИМЯ
iso_8859-11 - набор символов ISO 8859-11, представленный восьмеричным, десятичным и шестнадцатеричным кодом

## ОПИСАНИЕ
Стандарт ISO 8859 включает в себя несколько 8-битных расширений набора символов ASCII (также известной как ISO 646-IRV). В ISO 8859-11 кодируются символы, используемые в тайском языке.

### алфавиты ISO 8859
Полный набор алфавитов ISO 8859 включает в себя:

ISO 8859-1

западноевропейские языки (Latin-1)

ISO 8859-2

центрально- и восточноевропейские языки (Latin-2)

ISO 8859-3

языки юго-восточной Европы и другие языки (Latin-3)

ISO 8859-4

скандинавские/балтийские языки (Latin-4)

ISO 8859-5

латинский/кириллица

ISO 8859-6

латинский/арабский

ISO 8859-7

латинский/греческий

ISO 8859-8

латинский/иврит

ISO 8859-9

вариант Latin-1 для турецкого алфавита (Latin-5)

ISO 8859-10

саамский/скандинавский/эскимосский языки (Latin-6)

ISO 8859-11

латинский/тайский

ISO 8859-13

балтийские языки (Latin-7)

ISO 8859-14

кельтский (Latin-8)

ISO 8859-15

западноевропейские языки (Latin-9)

ISO 8859-16

румынский (Latin-10)

### символы ISO 8859-11
В следующей таблице показаны символы из набора ISO 8859-11, являющиеся печатными и отсутствующие в справочной странице ascii(7).

Вос

Дес

Шес

Симв

Описание

240

160

A0

НЕРАЗРЫВНЫЙ ПРОБЕЛ

241

161

A1

ก

ТАЙСКИЙ СИМВОЛ «КО КЯ»

242

162

A2

ข

ТАЙСКИЙ СИМВОЛ «ХО КХЯ»

243

163

A3

ฃ

ТАЙСКИЙ СИМВОЛ «ХО ХУАТ»

244

164

A4

ค

ТАЙСКИЙ СИМВОЛ «ХО КХВЯ»

245

165

A5

ฅ

ТАЙСКИЙ СИМВОЛ «КХО КХОН»

246

166

A6

ฆ

ТАЙСКИЙ СИМВОЛ «КХО РАКХАНГ»

247

167

A7

ง

ТАЙСКИЙ СИМВОЛ «НГО НГУ»

250

168

A8

จ

ТАЙСКИЙ СИМВОЛ «ЧО ЧАН»

251

169

A9

ฉ

ТАЙСКИЙ СИМВОЛ «ЧО ЧИНГ»

252

170

AA

ช

ТАЙСКИЙ СИМВОЛ «ЧО ЧАНГ»

253

171

AB

ซ

ТАЙСКИЙ СИМВОЛ «СО СО»

254

172

AC

ฌ

ТАЙСКИЙ СИМВОЛ «ЧО ЧОЁ»

255

173

AD

ญ

ТАЙСКИЙ СИМВОЛ «Ё ЕИНГ»

256

174

AE

ฎ

ТАЙСКИЙ СИМВОЛ «ДО ЧАДА»

257

175

AF

ฏ

ТАЙСКИЙ СИМВОЛ «ТО ПАТАК»

260

176

B0

ฐ

ТАЙСКИЙ СИМВОЛ «ФО ФАН»

261

177

B1

ฑ

ТАЙСКИЙ СИМВОЛ «НАНГМОНФ»

262

178

B2

ฒ

ТАЙСКИЙ СИМВОЛ «ФО ФУХАО»

263

179

B3

ณ

ТАЙСКИЙ СИМВОЛ «НО НЕН»

264

180

B4

ด

ТАЙСКИЙ СИМВОЛ «ДО ДЕК»

265

181

B5

ต

ТАЙСКИЙ СИМВОЛ «ТО ТАО»

266

182

B6

ถ

ТАЙСКИЙ СИМВОЛ «ФО ХУНГ»

267

183

B7

ท

ТАЙСКИЙ СИМВОЛ «ФО ХАНАН»

270

184

B8

ธ

ТАЙСКИЙ СИМВОЛ «ХО ХОНГ»

271

185

B9

น

ТАЙСКИЙ СИМВОЛ «НО НЮ»

272

186

BA

บ

ТАЙСКИЙ СИМВОЛ «ВО ВЯМЯ»

273

187

BB

ป

ТАЙСКИЙ СИМВОЛ «ПО ПЛА»

274

188

BC

ผ

ТАЙСКИЙ СИМВОЛ «ФО ФУНГ»

275

189

BD

ฝ

ТАЙСКИЙ СИМВОЛ «ФО ФА»

276

190

BE

พ

ТАЙСКИЙ СИМВОЛ «ФО ФАН»

277

191

BF

ฟ

ТАЙСКИЙ СИМВОЛ «ФФО ФФАН»

300

192

C0

ภ

ТАЙСКИЙ СИМВОЛ «ФО САМФАО»

301

193

C1

ม

ТАЙСКИЙ СИМВОЛ «МО МА»

302

194

C2

ย

ТАЙСКИЙ СИМВОЛ «Ё ЯК»

303

195

C3

ร

ТАЙСКИЙ СИМВОЛ «РО РЮ»

304

196

C4

ฤ

ТАЙСКИЙ СИМВОЛ «РУ»

305

197

C5

ล

ТАЙСКИЙ СИМВОЛ «ЛО ЛИНГ»

306

198

C6

ฦ

ТАЙСКИЙ СИМВОЛ «ЛУ»

307

199

C7

ว

ТАЙСКИЙ СИМВОЛ «ВО ВЯНЬ»

310

200

C8

ศ

ТАЙСКИЙ СИМВОЛ «СО САЛА»

311

201

C9

ษ

ТАЙСКИЙ СИМВОЛ «СО РУСИ»

312

202

CA

ส

ТАЙСКИЙ СИМВОЛ «СО СЮ»

313

203

CB

ห

ТАЙСКИЙ СИМВОЛ «ХО ШИП»

314

204

CC

ฬ

ТАЙСКИЙ СИМВОЛ «ЛО ЧУЛА»

315

205

CD

อ

ТАЙСКИЙ СИМВОЛ «О АНГ»

316

206

CE

ฮ

ТАЙСКИЙ СИМВОЛ «ХО НОХУК»

317

207

CF

ฯ

ТАЙСКИЙ СИМВОЛ «ФАЯАННОИ»

320

208

D0

ะ

ТАЙСКИЙ СИМВОЛ «САРА А»

321

209

D1

ั

ТАЙСКИЙ СИМВОЛ «МАЙ ХАН-АКАТ»

322

210

D2

า

ТАЙСКИЙ СИМВОЛ «САРА АА»

323

211

D3

ำ

ТАЙСКИЙ СИМВОЛ «САРА АМ»

324

212

D4

ิ

ТАЙСКИЙ СИМВОЛ «САРА И»

325

213

D5

ี

ТАЙСКИЙ СИМВОЛ «САРА ИИ»

326

214

D6

ึ

ТАЙСКИЙ СИМВОЛ «САРА УЕ»

327

215

D7

ื

ТАЙСКИЙ СИМВОЛ «САРА УЕЕ»

330

216

D8

ุ

ТАЙСКИЙ СИМВОЛ «САРА У»

331

217

D9

ู

ТАЙСКИЙ СИМВОЛ «САРА Ю»

332

218

DA

ฺ

ТАЙСКИЙ СИМВОЛ «ФИНХУ»

337

223

DF

฿

СИМВОЛ ТАЙСКОЙ ВАЛЮТЫ БАТ

340

224

E0

เ

ТАЙСКИЙ СИМВОЛ «САРА Е»

341

225

E1

แ

ТАЙСКИЙ СИМВОЛ «САРА АЕ»

342

226

E2

โ

ТАЙСКИЙ СИМВОЛ «САРА О»

343

227

E3

ใ

ТАЙСКИЙ СИМВОЛ «САРА Я МАЯМЮАН»

344

228

E4

ไ

ТАЙСКИЙ СИМВОЛ «САРА Я МАЯМАЛЯ»

345

229

E5

ๅ

ТАЙСКИЙ СИМВОЛ «ЛАКХАТГЫАО»

346

230

E6

ๆ

ТАЙСКИЙ СИМВОЛ «МАЯАМОК»

347

231

E7

็

ТАЙСКИЙ СИМВОЛ «МАЙТАЙХУ»

350

232

E8

่

ТАЙСКИЙ СИМВОЛ «МАЙ ЙИК»

351

233

E9

้

ТАЙСКИЙ СИМВОЛ «МАЙ ХО»

352

234

EA

๊

ТАЙСКИЙ СИМВОЛ «МАЙ ТРИ»

353

235

EB

๋

ТАЙСКИЙ СИМВОЛ «МАЙ ЧАТТАВА»

354

236

EC

์

ТАЙСКИЙ СИМВОЛ «ХАНХАХАТ»

355

237

ED

ํ

ТАЙСКИЙ СИМВОЛ «НИХАНЬТ»

356

238

EE

๎

ТАЙСКИЙ СИМВОЛ «ЯМАККАН»

357

239

EF

๏

ТАЙСКИЙ СИМВОЛ «ФОНГМАН»

360

240

F0

๐

ТАЙСКАЯ ЦИФРА НОЛЬ

361

241

F1

๑

ТАЙСКАЯ ЦИФРА ОДИН

362

242

F2

๒

ТАЙСКАЯ ЦИФРА ДВА

363

243

F3

๓

ТАЙСКАЯ ЦИФРА ТРИ

364

244

F4

๔

ТАЙСКАЯ ЦИФРА ЧЕТЫРЕ

365

245

F5

๕

ТАЙСКАЯ ЦИФРА ПЯТЬ

366

246

F6

๖

ТАЙСКАЯ ЦИФРА ШЕСТЬ

367

247

F7

๗

ТАЙСКАЯ ЦИФРА СЕМЬ

370

248

F8

๘

ТАЙСКАЯ ЦИФРА ВОСЕМЬ

371

249

F9

๙

ТАЙСКАЯ ЦИФРА ДЕВЯТЬ

372

250

FA

๚

ТАЙСКИЙ СИМВОЛ «АНГХАНХУ»

373

251

FB

๛

ТАЙСКИЙ СИМВОЛ «ХОМУТ»

## ЗАМЕЧАНИЯ
ISO 8859-11 совпадает с TIS (Тайский индустриальный стандарт, Thai Industrial Standard) 620-2253, известном как TIS-620, за исключением символа в позиции A0: в ISO 8859-11 там определён «неразрывный пробел», а в TIS-620 отсутствует какой-либо символ.

## СМОТРИТЕ ТАКЖЕ
ascii(7), charsets(7), utf-8(7)