package: man-pages-ru

title: address_families(7)

summary: семейства адресов сокетов (домены)

text:
# address_families(7)

## ИМЯ
address_families - семейства адресов сокетов (домены)

## ОБЗОР
\#include <sys/types.h> /* смотрите ЗАМЕЧАНИЯ */

\#include <sys/socket.h>

int socket(int domain, int type, int protocol);

## ОПИСАНИЕ
Параметр domain в socket(2) задает домен соединения: выбирает семейство протоколов, которое будет использоваться для соединения. Семейства описаны в <sys/socket.h>. В настоящее время ядром Linux распознаются следующие форматы:

AF_UNIX, AF_LOCAL

Локальное соединение, дополнительная информация доступна в unix(7).

AF_INET

Протоколы Интернет IPv4, дополнительная информация доступна в ip(7).

AF_AX25

Протокол любительского радио AX.25, дополнительная информация доступна в ax25(4).

AF_IPX

Протоколы Novell IPX.

AF_APPLETALK

AppleTalk, дополнительная информация доступна в ddp(7).

AF_NETROM

Протокол пакетного уровня AX.25, дополнительная информация доступна в netrom(4), The Packet Radio Protocols and Linux и AX.25, NET/ROM и главах ROSE network programming из Linux Amateur Radio AX.25 HOWTO.

AF_BRIDGE

Нельзя использовать для создания сокетов; в основном используется для связей типа «мост» в протокольных командах rtnetlink(7).

AF_ATMPVC

Доступ к неструктурированным постоянным виртуальным каналам ATM (PVC), дополнительная информация доступна в ATM on Linux HOWTO.

AF_X25

Протокол ITU-T X.25 / ISO-8208, дополнительная информация доступна в x25(7).

AF_INET6

Протоколы Интернет IPv6, дополнительная информация доступна в ipv6(7).

AF_ROSE

Протокол пакетного уровня RATS (Radio Amateur Telecommunications Society) окружения открытых систем (ROSE) AX.25, дополнительная информация доступна в ресурсах, перечисленных для AF_NETROM.

AF_DECnet

Протокольные сокеты DECet, дополнительная информация доступна в Documentation/networking/decnet.txt из дерева исходного кода Linux.

AF_NETBEUI

Зарезервировано для «проекта 802.2LLC», никогда не использовалось.

AF_SECURITY

Недолго существовавшее (с Linux 2.1.30 по 2.1.99pre2) семейство протоколов для вызовов из межсетевого экрана.

AF_KEY

Прокотол управления ключами, изначально разрабатывался для использования с IPsec (начиная с Linux 2.1.38). Никак не связан с keyctl(2) и возможностью хранения ключей в ядре. Дополнительная информация доступна в RFC 2367 PF_KEY Key Management API, Version 2

AF_NETLINK

Устройство для пользовательского взаимодействия с ядром, дополнительная информация доступна в netlink(7).

AF_PACKET

Низкоуровневый пакетный интерфейс, дополнительная информация доступна в packet(7).

AF_ECONET

Протокол Acorn Econet (удалён в Linux 3.5); дополнительная информация доступна в Econet documentation

AF_ATMSVC

Доступ к коммутируемым виртуальным каналам ATM (SVC); дополнительная информация доступна в ATM on Linux HOWTO

AF_RDS

Протокол надёжных датаграммных сокетов (RDS) (начиная с Linux 2.6.30). RDS поверх RDMA никак не связан с AF_SMC или AF_XDP. Дополнительная информация доступна в rds(7), rds-rdma(7) и файле Documentation/networking/rds.txt из дерева исходного кода Linux.

AF_IRDA

Сокетный интерфейс поверх IrDA (помещён для обкатки в Linux 4.14, удалён Linux 4.17); дополнительная информация доступна в irda(7).

AF_PPPOX

Транспортный слой PPP общего назначения для поднятия туннелей L2 (L2TP и PPPoE). Смотрите файл Documentation/networking/l2tp.txt в дереве исходного кода Linux.

AF_WANPIPE

Устаревший протокол для территориально распределённой сети (WAN), использовался в картах Sangoma WAN («WANPIPE»); удалён в Linux 2.6.21.

AF_LLC

Протокол управления логической связью (IEEE 802.2 LLC), верхних подуровень канального уровня сетевого стека протоколов ISO/OSI (начиная с Linux 2.4); никак не связан с AF_PACKET. Смотрите главу 13.5.3. Logical Link Control в Understanding Linux Kernel Internals (O'Reilly Media, 2006) и IEEE Standards for Local Area Networks: Logical Link Control (The Institute of Electronics and Electronics Engineers, Inc., New York, New York, 1985). В исторических заметках описана разработка протокола.

AF_IB

Собственная адресация InfiniBand (начиная с Linux 3.11).

AF_MPLS

Многопротокольная коммутация по меткам (начиная с Linux 4.1); по большей части используется для настройки маршрутизации MPLS через netlink(7), так как нет возможности создавать сокеты в пользовательском пространстве.

AF_CAN

Автотранспортный протокол шины Controller Area Network (начиная с Linux 2.6.25). Дополнительную информацию смотрите в файле Documentation/networking/can.rst в дереве исходного кода Linux.

AF_TIPC

TIPC, протокол «кластерных доменных сокетов» (начиная с Linux 2.6.16). Смотрите TIPC Programmer's Guide и описание протокола

AF_BLUETOOTH

Сокетный протокол Bluetooth низкого уровня (начиная с Linux 3.11). Описан в Bluetooth Management API overview и An Introduction to Bluetooth Programming Альбертом Хуангом (Albert Huang)

AF_IUCV

Протокол IUCV (средство межпользовательской связи) z/VM для взаимодействия гипервизор-гость (начиная с Linux 2.6.21); никак не связан с AF_VSOCK и/или AF_SMC. Дополнительную информацию смотрите в IUCV protocol overview

AF_RXRPC

Rx, протокол процедурных вызовов Andrew File System (начиная с Linux 2.6.22).Дополнительную информацию смотрите в файле Documentation/networking/rxrpc.txt дерева исходного кода Linux.

AF_ISDN

Новый протокол взаимодействия с драйвером «модульного ISDN» (начиная с Linux 2.6.27). Смотрите вики mISDN

AF_PHONET

Интерфейс IPC/RPC к сотовому модему Nokia (начиная с Linux 2.6.31). Дополнительную информацию смотрите в файле Documentation/networking/phonet.txt дерева исходного кода Linux.

AF_IEEE802154

Неструктурированный пакетный протокол IEEE 802.15.4 WPAN (персональная беспроводная сеть) (начиная с Linux 2.6.31). Дополнительную информацию смотрите в файле Documentation/networking/ieee802154.txt дерева исходного кода Linux.

AF_CAIF

Протокол взаимодействия Ericsson Communication CPU с Application CPU (CAIF)(начиная с Linux 2.6.36). Дополнительную информацию смотрите в файле Documentation/networking/caif/Linux-CAIF.txt дерева исходного кода Linux.

AF_ALG

Взаимодействие с ядерным интерфейсом шифрования (начиная с Linux 2.6.38). Дополнительную информацию смотрите в файле Documentation/crypto/userspace-if.rst дерева исходного кода Linux.

AF_VSOCK

Протокол VMWare VSockets для взаимодействия гипервизор-гость (начиная с Linux 3.9);никак не связан с AF_IUCV и AF_SMC. Дополнительную информацию смотрите в vsock(7).

AF_KCM

Интерфейс KCM (концентратор соединений ядра) (начиная с Linux 4.6). Дополнительную информацию смотрите в файле Documentation/networking/kcm.txt дерева исходного кода Linux.

AF_QIPCRTR

Протокол взаимодействия с маршрутизатором Qualcomm IPC (начиная с Linux 4.7).

AF_SMC

Протокол SMC-R (подключения к общей памяти через RDMA) (начиная с Linux 4.11), и протокол SMC-D (подключения к общей памяти, прямой доступ к памяти) для межузлового гостевого взаимодействия z/VM (начиная с Linux 4.19); никак не связан с AF_RDS, AF_IUCV или AF_VSOCK. В RFC 7609 IBM's Shared Memory Communications over RDMA (SMC-R) Protocol приведена информация по SMC-R. В SMC-D Reference Information приведена информация по SMC-D.

AF_XDP

Интерфейс XDP (короткий путь прохождения данных) (начиная с Linux 4.18). Дополнительную информацию смотрите в файле Documentation/networking/af_xdp.rst дерева исходного кода Linux.

## СМОТРИТЕ ТАКЖЕ
socket(2), socket(7)


aio

title: aio(7)

summary: введение в асинхронный ввод\-вывод POSIX

text:
# aio(7)

## ИМЯ
aio - введение в асинхронный ввод-вывод POSIX

## ОПИСАНИЕ
Интерфейс асинхронного ввода-вывода POSIX (AIO) позволяет приложениям запускать одну или несколько операций ввода-вывода, которые выполняются асинхронно (т. е., в фоновом режиме). Приложение может выбрать каким образом оно будет уведомлено о завершении операции ввода-вывода: с помощью сигнала, созданием новой нити или вообще не получать уведомления.

Интерфейс POSIX AIO состоит из следующих функций:

aio_read(3)

Ставит запрос на чтение в очередь. Это асинхронный аналог read(2).

aio_write(3)

Ставит запрос на запись в очередь. Это асинхронный аналог write(2).

aio_fsync(3)

Ставит запрос синхронизации операций ввода-вывода над файловым дескриптором. Это асинхронный аналог fsync(2) и fdatasync(2).

aio_error(3)

Возвращает информацию о состоянии поставленного в очередь запроса ввода-вывода.

aio_return(3)

Возвращает информацию о выполненном запросе ввода-вывода.

aio_suspend(3)

Приостанавливает вызывающего до тех пор, пока не выполнится один или более указанных запросов ввода-вывода.

aio_cancel(3)

Пытается отменить ожидающие выполнения запросы ввода-вывода над заданным файловым дескриптором.

lio_listio(3)

Ставит в очередь сразу несколько запросов ввода-вывода за один вызов функции.

В структуре aiocb («блок управления асинхронным вводом-выводом») задаются параметры, которые управляют операцией ввода-вывода. Аргумент данного типа передаётся во все функции, перечисленные ранее. Данная структура имеет следующий вид:

```
#include <aiocb.h>
struct aiocb {

    /* Порядок данных полей определяется реализацией */

    int             aio_fildes;     /* файловый дескриптор */

    off_t           aio_offset;     /* файловое смещение */

    volatile void  *aio_buf;        /* расположение буфера */

    size_t          aio_nbytes;     /* длина передачи */

    int             aio_reqprio;    /* приоритет запроса */

    struct sigevent aio_sigevent;   /* метод уведомления */

    int             aio_lio_opcode; /* выполняемая операция;

                                       только в lio_listio() */

    /* Не показаны различные поля, используемые в реализациях */
};
/* Коды операций для 'aio_lio_opcode': */
enum { LIO_READ, LIO_WRITE, LIO_NOP };
```

Поля этой структуры имеют следующее назначение:

aio_fildes

Файловый дескриптор, над которым будут выполняться операции ввода-вывода.

aio_offset

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

aio_buf

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

aio_nbytes

Размер буфера, на который указывает aio_buf.

aio_reqprio

В этом поле задаётся значение, которое вычитается из приоритета реального времени вызывающей нити, чтобы определить приоритет выполнения данного запроса ввода-вывода (смотрите pthread_setschedparam(3)). Указываемое значение должно быть в диапазоне от 0 и до значения, возвращаемого sysconf(_SC_AIO_PRIO_DELTA_MAX). Данное поле игнорируется при операциях синхронизации файла.

aio_sigevent

В этом поле задаётся структура, которая указывает как вызывающему должно быть сообщено о завершении анонимной операции ввода-вывода. Возможные значения для aio_sigevent.sigev_notify: SIGEV_NONE, SIGEV_SIGNAL и SIGEV_THREAD. Подробности смотрите в sigevent(7).

aio_lio_opcode

Задаёт тип операции, которая будет выполнена; используется только в lio_listio(3).

В дополнении к стандартным функциям, перечисленным ранее, в библиотеке GNU C есть следующее расширение программного интерфейса POSIX AIO:

aio_init(3)

Позволяет изменить настройки поведения реализации glibc для POSIX AIO.

## ОШИБКИ
EINVAL

Значение поля aio_reqprio структуры aiocb меньше 0 или больше, чем значение ограничения, возвращаемое вызовом sysconf(_SC_AIO_PRIO_DELTA_MAX).

## ВЕРСИИ
Интерфейсы POSIX AIO появились в glibc в версии 2.1.

## СООТВЕТСТВИЕ СТАНДАРТАМ
POSIX.1-2001, POSIX.1-2008.

## ЗАМЕЧАНИЯ
Желательно обнулять буфер блока управления перед использованием (смотрите memset(3)). Буфер блока управления и буфер, который задаётся в aio_buf, не должны изменяться во время выполнения операции ввода-вывода. Данные буферы должны оставаться рабочими до завершения операции ввода-вывода.

Одновременное выполнение операций чтения или записи через совместно используемую структуру aiocb приводит к непредсказуемым результатам.

Имеющаяся реализация Linux POSIX AIO предоставляется glibc в пользовательском пространстве. Она имеет ряд ограничений, наиболее существенные из которых — затраты на сопровождение нескольких нитей при операциях ввода-вывода и плохое масштабирование. Некогда для реализации асинхронного ввода-вывода велась работа над ядерной реализацией на основе машины состояний (смотрите io_submit(2), io_setup(2), io_cancel(2), io_destroy(2), io_getevents(2)), но эта реализация ещё недостаточно стабильна в тех местах, где POSIX AIO можно было бы полностью реализовать на системных вызовах ядра.

## ПРИМЕР
Представленная далее программа открывает все файлы, указанные в параметрах командной строки и ставит в очередь запрос на полученные файловые дескрипторы с помощью aio_read(3). Затем программа входит в цикл, в котором периодически следит за всеми выполняемыми операциями ввода-вывода с помощью aio_error(3). Для каждого запроса ввода-вывода настроено получение уведомления посредством сигнала. После завершения всех запросов ввода-вывода, программа возвращает их состояние с помощью aio_return(3).

Сигнал SIGQUIT (генерируемый нажатием control-\) заставляет программу отменить все невыполненные запросы с помощью aio_cancel(3).

Вот результат работы программы. В этом примере программа ставит в очередь два запроса для стандартного ввода, и они отрабатываются двумя введёнными строками «abc» и «x».

```
$ ./a.out /dev/stdin /dev/stdin
открыт /dev/stdin в дескрипторе 3
открыт /dev/stdin в дескрипторе 4
aio_error():

    запрос 0 (дескриптор 3): выполняется

    запрос 1 (дескриптор 4): выполняется
abc
Получен сигнал завершения ввода-вывода
aio_error():

    запрос 0 (дескриптор 3): ввод-вывод завершён

    запрос 1 (дескриптор 4): выполняется
aio_error():

    запрос 1 (дескриптор 4): выполняется
x
Получен сигнал завершения ввода-вывода
aio_error():

    запрос 1 (дескриптор 4): ввод-вывод завершён
Завершены все запросы ввода-вывода
aio_return():

    запрос 0 (дескриптор 3): 4

    запрос 1 (дескриптор 4): 2
```

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

```
#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
#include <aio.h>
#include <signal.h>
#define BUF_SIZE 20     /* размер буферов для операций чтения */
#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0)
#define errMsg(msg)  do { perror(msg); } while (0)
struct ioRequest {      /* определяемая приложением структура для

                           слежения за запросами ввода-вывода */

    int           reqNum;

    int           status;

    struct aiocb *aiocbp;
};
static volatile sig_atomic_t gotSIGQUIT = 0;

                        /* при получении SIGQUIT мы пытаемся отменить

                           все невыполненные запросы ввода-вывода */
static void             /* обработчик SIGQUIT */
quitHandler(int sig)
{

    gotSIGQUIT = 1;
}
#define IO_SIGNAL SIGUSR1   /* сигнал, уведомляющий о завершении

                               ввода-вывода */
static void                 /* обработчик завершения ввода-вывода */
aioSigHandler(int sig, siginfo_t *si, void *ucontext)
{

    if (si->si_code == SI_ASYNCIO) {

        write(STDOUT_FILENO, "Получен сигнал завершения ввода-вывода\n", 31);

        /* соответствующая структура ioRequest была бы доступна как

               struct ioRequest *ioReq = si->si_value.sival_ptr;

           а файловый дескриптор был бы доступен через

               ioReq->aiocbp->aio_fildes */

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

    struct ioRequest *ioList;

    struct aiocb *aiocbList;

    struct sigaction sa;

    int s, j;

    int numReqs;        /* общее количество устанавливаемых в очередь

                           запросов ввода-вывода */

    int openReqs;       /* количество выполняющихся запросов

                           ввода-вывода */

    if (argc < 2) {

        fprintf(stderr, "Использование: %s <имя_файла> <имя_файла>...\n",

                argv[0]);

        exit(EXIT_FAILURE);

    }

    numReqs = argc - 1;

    /* выделяем место под массивы */

    ioList = calloc(numReqs, sizeof(struct ioRequest));

    if (ioList == NULL)

        errExit("calloc");

    aiocbList = calloc(numReqs, sizeof(struct aiocb));

    if (aiocbList == NULL)

        errExit("calloc");

    /* указываем обработчики SIGQUIT и сигнала завершения ввода-вывода */

    sa.sa_flags = SA_RESTART;

    sigemptyset(&sa.sa_mask);

    sa.sa_handler = quitHandler;

    if (sigaction(SIGQUIT, &sa, NULL) == -1)

        errExit("sigaction");

    sa.sa_flags = SA_RESTART | SA_SIGINFO;

    sa.sa_sigaction = aioSigHandler;

    if (sigaction(IO_SIGNAL, &sa, NULL) == -1)

        errExit("sigaction");

    /* открываем каждый файл, заданный в командной строке и ставим в

       очередь запрос на чтение полученного файлового дескриптора */

    for (j = 0; j < numReqs; j++) {

        ioList[j].reqNum = j;

        ioList[j].status = EINPROGRESS;

        ioList[j].aiocbp = &aiocbList[j];

        ioList[j].aiocbp->aio_fildes = open(argv[j + 1], O_RDONLY);

        if (ioList[j].aiocbp->aio_fildes == -1)

            errExit("open");

        printf("opened %s on descriptor %d\n", argv[j + 1],

                ioList[j].aiocbp->aio_fildes);

        ioList[j].aiocbp->aio_buf = malloc(BUF_SIZE);

        if (ioList[j].aiocbp->aio_buf == NULL)

            errExit("malloc");

        ioList[j].aiocbp->aio_nbytes = BUF_SIZE;

        ioList[j].aiocbp->aio_reqprio = 0;

        ioList[j].aiocbp->aio_offset = 0;

        ioList[j].aiocbp->aio_sigevent.sigev_notify = SIGEV_SIGNAL;

        ioList[j].aiocbp->aio_sigevent.sigev_signo = IO_SIGNAL;

        ioList[j].aiocbp->aio_sigevent.sigev_value.sival_ptr =

                                &ioList[j];

        s = aio_read(ioList[j].aiocbp);

        if (s == -1)

            errExit("aio_read");

    }

    openReqs = numReqs;

    /* цикл, отслеживание состояние запросов ввода-вывода */

    while (openReqs > 0) {

        sleep(3);       /* задержка между проверками */

        if (gotSIGQUIT) {

            /* при получении SIGQUIT пытаемся отменить каждый

               невыполненный запрос ввода-вывода и показываем состояние,

               возвращаемое при отмене запроса */

            printf("получен SIGQUIT; отмена запросов ввода-вывода: \n");

            for (j = 0; j < numReqs; j++) {

                if (ioList[j].status == EINPROGRESS) {

                    printf("    запрос %d в дескриптор %d:", j,

                            ioList[j].aiocbp->aio_fildes);

                    s = aio_cancel(ioList[j].aiocbp->aio_fildes,

                            ioList[j].aiocbp);

                    if (s == AIO_CANCELED)

                        printf("ввод-вывод отменён\n");

                    else if (s == AIO_NOTCANCELED)

                        printf("ввод-вывод не отменён\n");

                    else if (s == AIO_ALLDONE)

                        printf("I/O all done\n");

                    else

                        errMsg("aio_cancel");

                }

            }

            gotSIGQUIT = 0;

        }

        /* проверяем состояние каждого запроса ввода-вывода, которые

           ещё не завершились */

        printf("aio_error():\n");

        for (j = 0; j < numReqs; j++) {

            if (ioList[j].status == EINPROGRESS) {

                printf("    запрос %d (дескриптор %d): ",

                        j, ioList[j].aiocbp->aio_fildes);

                ioList[j].status = aio_error(ioList[j].aiocbp);

                switch (ioList[j].status) {

                case 0:

                    printf("ввод-вывод завершён\n");

                    break;

                case EINPROGRESS:

                    printf("выполняется\n");

                    break;

                case ECANCELED:

                    printf("отменён\n");

                    break;

                default:

                    errMsg("aio_error");

                    break;

                }

                if (ioList[j].status != EINPROGRESS)

                    openReqs--;

            }

        }

    }

    printf("Завершены все запросы ввода-вывода\n");

    /* проверяем возвращаемое состояние всех запросов ввода-вывода */

    printf("aio_return():\n");

    for (j = 0; j < numReqs; j++) {

        ssize_t s;

        s = aio_return(ioList[j].aiocbp);

        printf("    запрос %d (дескриптор %d): %zd\n",

                j, ioList[j].aiocbp->aio_fildes, s);

    }

    exit(EXIT_SUCCESS);
}
```

## СМОТРИТЕ ТАКЖЕ
io_cancel(2), io_destroy(2), io_getevents(2), io_setup(2), io_submit(2), aio_cancel(3), aio_error(3), aio_init(3), aio_read(3), aio_return(3), aio_write(3), lio_listio(3)

«Asynchronous I/O Support in Linux 2.5», Bhattacharya, Pratt, Pulavarty, and Morgan, Proceedings of the Linux Symposium, 2003, https://www.kernel.org/doc/ols/2003/ols2003-pages-351-366.pdf


title: armscii-8(7)

text:
# armscii-8(7)

## ИМЯ
armscii-8 - Набор армянских символов в восьмеричной, десятичной и шестнадцатеричной системах счисления

## ОПИСАНИЕ
Армянский стандартный код для обмена информацией; 8-битный набор символов.

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

Вос

Дес

Шес

Симв

Описание

240

160

A0

неразрывный пробел

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

Յ

армянская заглавная буква йи

333

219

DB

յ

армянская строчная буква йи

334

220

DC

Ն

армянская заглавная буква ну

335

221

DD

ն

армянская строчная буква ну

336

222

DE

Շ

армянская заглавная буква ша

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

օ

армянская строчная буква о

374

252

FC

Ֆ

армянская заглавная буква фе

375

253

FD

ֆ

армянская строчная буква фе

376

254

FE

՚

армянский знак апострофа

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


arp

title: arp(7)

summary: модуль ядра Linux для ARP

text:
# arp(7)

## ИМЯ
arp - модуль ядра Linux для ARP

## ОПИСАНИЕ
Этот модуль ядра реализует Address Resolution Protocol (протокол разрешения адресов), определённый в RFC 826. Протокол предназначен для преобразования аппаратных адресов второго уровня (Layer2) в адреса протокола IPv4 в соединённых напрямую сетях. Как правило, пользователю не приходится работать с этим модулем непосредственно, исключая случаи его настройки — модуль используется другими протоколами ядра.

Процесс пользователя может получать пакеты ARP через сокеты packet(7). Кроме того, существует механизм управления кэшем ARP из пространства пользователя с помощью сокетов netlink(7). Таблицей ARP также можно управлять с помощью ioctl (2) из произвольного сокета AF_INET.

Модуль ARP поддерживает кэш отображения аппаратных адресов в протокольные адреса. Размер кэша ограничен, поэтому старые и мало используемые записи удаляются. Записи, помеченные как постоянные, не удаляются никогда. Кэшем можно управлять непосредственно, с помощью ioctl-вызовов. Работа кэша может быть настроена с помощью интерфейсов /proc, описанных ниже.

Если в течение некоторого времени (см. /proc интерфейсы ниже) не подтверждается корректность (positive feedback) существующей записи кэша, то она считается устаревшей. Подтверждение может быть получено от более высокого уровня, например, при получении TCP ACK. Другие протоколы могут выполнить подтверждение, используя флаг MSG_CONFIRM при вызове sendmsg(2). Если подтверждения нет, то ARP пытается повторить запрос. Сначала он пытается запросить обновлённый MAC-адрес у локальной службы arp app_solicit раз. Если получить адрес не удалось, а старый MAC-адрес известен, то посылается адресный запрос ucast_solicit раз. Если и после этого адрес определить не удалось, то по сети посылается новый широковещательный ARP-запрос. Запросы посылаются только при наличии данных в очереди для отправки.

Linux автоматически добавляет динамическую запись proxy arp, когда система получает запрос адреса, для которого она производит пересылку и если proxy arp включён на принимающем интерфейсе. При наличии маршрута отказа (reject route) добавление proxy arp не производится.

### Вызовы ioctl
Для всех сокетов AF_INET доступно три ioctl-вызова. В качестве параметра ожидается указатель на структуру struct arpreq.

```
struct arpreq {

    struct sockaddr arp_pa;      /* адрес протокола */

    struct sockaddr arp_ha;      /* аппаратный адрес */

    int             arp_flags;   /* флаги */

    struct sockaddr arp_netmask; /* сетевая маска адреса протокола */

    char            arp_dev[16];
};
```

Вызовы SIOCSARP, SIOCDARP и SIOCGARP соответственно устанавливают, удаляют и считывают отображение ARP. Для установки или удаления отображений ARP процесс должен иметь мандат CAP_NET_ADMIN или эффективный UID, равный 0.

Поле arp_pa должно быть сокетом AF_INET, а arp_ha должно иметь тот же тип, что и тип устройства, указанный в arp_dev. Поле arp_dev — строка с именем устройства, оканчивающаяся нулем.

arp_flags

флаг

значение

ATF_COM

Поиск окончен

ATF_PERM

Постоянная запись

ATF_PUBL

Анонсировать запись

ATF_USETRAILERS

Требуются концевики

ATF_NETMASK

Использовать маску сети

ATF_DONTPUB

Не отвечать

Если установлен флаг ATF_NETMASK, то должно быть указано корректное значение arp_netmask. Linux 2.2 не поддерживает сетевые записи proxy ARP, поэтому для удаления существующих записей proxy arp это значение должно быть равно 0xffffffff или 0. Флаг ATF_USETRAILERS считается устаревшим и не должен использоваться.

### Интерфейсы /proc
ARP поддерживает /proc интерфейсы для настройки общих параметров или параметров конкретного сетевого интерфейса. Настройка осуществляется путём чтения или записи файлов /proc/sys/net/ipv4/neigh/*/*. Для каждого сетевого интерфейса в системе существует соответствующий каталог в /proc/sys/net/ipv4/neigh/. Настройки в каталоге «default» используются для всех новых создаваемых устройств. Если не определено явно, то считается, что время указывается в секундах.

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

Максимальное значение задержки в тиках (jiffies) до ответа на сообщение об объявлении соседей (neighbor solicitation message) IPv6. Поддержка anycast пока не реализована. Значение по умолчанию — 1 секунда.

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

Максимальное количество попыток послать запрос через сетевое соединение (netlink) ARP-службе в пользовательском пространстве до возврата к использованию многоадресных запросов (см. mcast_solicit). Значение по умолчанию — 0.

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

Если адрес был найден, то значение записи в диапазоне времени между base_reachable_time/2 и 3*base_reachable_time/2 будет считаться не устаревшим. Запись будет считаться правильной более длительное время, если будет получено подтверждение от протоколов более высокого уровня. Значение по умолчанию — 30 секунд.

base_reachable_time_ms (начиная с Linux 2.6.12)

Тоже, что и base_reachable_time, но время задаётся в миллисекундах. Значение по умолчанию — 30000 миллисекунд.

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

Задержка до первого запроса после того, как запись стала считаться устаревшей. Значение по умолчанию — 5 секунд.

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

Частота очистки кэша от устаревших и некорректных записей. Значение по умолчанию — 30 секунд.

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

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

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

Минимальное количество записей, хранимых в кэше ARP. Если количество записей меньше этого значения, то очистка кэша производится не будет. Значение по умолчанию — 128.

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

Мягкое ограничение максимального количества записей в кэше ARP. Если это значение будет превышено более, чем на 5 секунд, то будет произведена очистка кэша. Значение по умолчанию — 512.

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

Жёсткое ограничение количества записей в кэше ARP. Если это значение будет превышено, то будет произведена очистка кэша. Значение по умолчанию — 1024.

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

Минимальное время хранения записи в кэше в тиках. Предотвращает замусоривание кэша при наличии более одного возможного отображения (в общем случае, из-за неправильной настройки сети). Значение по умолчанию — 1 секунда.

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

Максимальное количество попыток определить адрес с помощью многоадресной/широковещательной передачи. Если адрес не будет обнаружен, то он будет помечен как недоступный. Значение по умолчанию — 3.

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

Задержка до proxy_delay тиков между получением ARP-запроса на известный proxy ARP-адрес и ответом. Предназначена для предотвращения перегрузки сети. Значение по умолчанию — 0.8 секунды.

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

Максимальное количество пакетов для адресов proxy ARP, которые могут быть отправлены в очередь . Значение по умолчанию — 64.

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

Задержка перед повторением запроса в тиках. Значение по умолчанию — 1 секунда. Этот файл устарел, используйте retrans_time_ms.

retrans_time_ms (начиная с Linux 2.6.12)

Задержка перед повторением запроса в миллисекундах. Значение по умолчанию — 1000 миллисекунд.

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

Максимальное количество попыток послать адресный запрос перед запросом службы ARP (см. app_solicit). Значение по умолчанию — 3.

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

Максимальное количество пакетов, которые могут быть поставлены в очередь протоколами других сетевых уровней для передачи по каждому неопределённому адресу. Значение по умолчанию — 3.

## ВЕРСИИ
В Linux 2.0 в структуру struct arpreq было включено поле arp_dev и изменены номера ioctl. Старые ioctl были удалены в Linux 2.2.

Поддержка записей proxy arp для сетей (маска сети не равна 0xffffffff) удалена в Linux 2.2. Вместо этого было реализовано автоматическое определение ядром всех доступных узлов через другие интерфейсы (если на интерфейсе включена пересылка и proxy arp).

Интерфейсы neigh/* не существовали до версии Linux 2.2.

## ДЕФЕКТЫ
Значения некоторых настроек указаны в тиках, длительность которых зависит от архитектуры компьютера и версии ядра; смотрите time(7).

Не существует способа отправить подтверждение из пользовательского пространства. Это означает, что протоколы, ориентированные на соединения и реализованные в пользовательском пространстве, будут создавать избыточный ARP-трафик, так как ndisc будет вновь и вновь запрашивать MAC-адрес. То же относится и к некоторым протоколам ядра (например, NFS через UDP).

В этой странице дано описание возможностей IPv4, а также общих возможностей IPv4 и IPv6.

## СМОТРИТЕ ТАКЖЕ
capabilities(7), ip(7), arpd(8)

Описание ARP приведено в RFC 826. Определение соседних машин согласно IPv6 и основные используемые алгоритмы приведены в RFC 2461. В Linux 2.2+ IPv4 ARP используются алгоритмы IPv6 (если это возможно).


ascii

title: ascii(7)

text:
# ascii(7)

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

## ОПИСАНИЕ
ASCII — американский стандартный код для обмена информацией. Это 7-битная кодировка. Многие 8-битные коды (например, ISO 8859-1) содержат ASCII в своих нижних половинах таблиц. Международный аналог ASCII также известен как ISO 646.IRV.

В следующей таблице содержатся 128 символов ASCII.

В программах на C используют экранированные версии ('\X').

Вос

Дес

Шес

Симв

Вос

Дес

Шес

Симв

000

0

00

NUL '\0' (символ null)

100

64

40

@

001

1

01

SOH (начало заголовка)

101

65

41

A

002

2

02

STX (начало текста)

102

66

42

B

003

3

03

ETX (конец текста)

103

67

43

C

004

4

04

EOT (конец передачи)

104

68

44

D

005

5

05

ENQ (запрос подтв.)

105

69

45

E

006

6

06

ACK (подтверждение)

106

70

46

F

007

7

07

BEL '\a' (звонок)

107

71

47

G

010

8

08

BS '\b' (забой)

110

72

48

H

011

9

09

HT '\t' (горизон. таб.)

111

73

49

I

012

10

0A

LF '\n' (перевод строки)

112

74

4A

J

013

11

0B

VT '\v' (верт. таб.)

113

75

4B

K

014

12

0C

FF '\f' (новая страница)

114

76

4C

L

015

13

0D

CR '\r' (возвр. каретки)

115

77

4D

M

016

14

0E

SO (смена ленты)

116

78

4E

N

017

15

0F

SI (обр. смена ленты)

117

79

4F

O

020

16

10

DLE (нач. спец. символов)

120

80

50

P

021

17

11

DC1 (1 сим. упр. устр.)

121

81

51

Q

022

18

12

DC2 (2 сим. упр. устр.)

122

82

52

R

023

19

13

DC3 (3 сим. упр. устр.)

123

83

53

S

024

20

14

DC4 (4 сим. упр. устр.)

124

84

54

T

025

21

15

NAK (отказ подтверж.)

125

85

55

U

026

22

16

SYN (синх. ожидание)

126

86

56

V

027

23

17

ETB (конец перед. блока)

127

87

57

W

030

24

18

CAN (отмена)

130

88

58

X

031

25

19

EM (конец носителя)

131

89

59

Y

032

26

1A

SUB (подстановка)

132

90

5A

Z

033

27

1B

ESC (начало спец. символа)

133

91

5B

[

034

28

1C

FS (разделитель файлов)

134

92

5C

\ '\\'

035

29

1D

GS (разделитель групп)

135

93

5D

]

036

30

1E

RS (разделитель записей)

136

94

5E

^

037

31

1F

US (раздел. элементов)

137

95

5F

_

040

32

20

ПРОБЕЛ

140

96

60

`

041

33

21

!

141

97

61

a

042

34

22

"

142

98

62

b

043

35

23

\#

143

99

63

c

044

36

24

$

144

100

64

d

045

37

25

%

145

101

65

e

046

38

26

&

146

102

66

f

047

39

27

'

147

103

67

g

050

40

28

(

150

104

68

h

051

41

29

)

151

105

69

i

052

42

2A

*

152

106

6A

j

053

43

2B

+

153

107

6B

k

054

44

2C

,

154

108

6C

l

055

45

2D

-

155

109

6D

m

056

46

2E

.

156

110

6E

n

057

47

2F

/

157

111

6F

o

060

48

30

0

160

112

70

p

061

49

31

1

161

113

71

q

062

50

32

2

162

114

72

r

063

51

33

3

163

115

73

s

064

52

34

4

164

116

74

t

065

53

35

5

165

117

75

u

066

54

36

6

166

118

76

v

067

55

37

7

167

119

77

w

070

56

38

8

170

120

78

x

071

57

39

9

171

121

79

y

072

58

3A

:

172

122

7A

z

073

59

3B

;

173

123

7B

{

074

60

3C

<

174

124

7C

|

075

61

3D

=

175

125

7D

}

076

62

3E

>

176

126

7E

~

077

63

3F

?

177

127

7F

DEL

### Таблицы
Для удобства далее представлены компактные таблицы шестнадцатеричных и десятичных кодов.

```
   2 3 4 5 6 7       30 40 50 60 70 80 90 100 110 120

 -------------      ---------------------------------
0:   0 @ P ` p     0:    (  2  <  F  P  Z  d   n   x
1: ! 1 A Q a q     1:    )  3  =  G  Q  [  e   o   y
2: " 2 B R b r     2:    *  4  >  H  R  \  f   p   z
3: # 3 C S c s     3: !  +  5  ?  I  S  ]  g   q   {
4: $ 4 D T d t     4: "  ,  6  @  J  T  ^  h   r   |
5: % 5 E U e u     5: #  -  7  A  K  U  _  i   s   }
6: & 6 F V f v     6: $  .  8  B  L  V  `  j   t   ~
7: ' 7 G W g w     7: %  /  9  C  M  W  a  k   u  DEL
8: ( 8 H X h x     8: &  0  :  D  N  X  b  l   v
9: ) 9 I Y i y     9: '  1  ;  E  O  Y  c  m   w
A: * : J Z j z
B: + ; K [ k {
C: , < L \ l |
D: - = M ] m }
E: . > N ^ n ~
F: / ? O _ o DEL
```

## ЗАМЕЧАНИЯ

### История
Справочная таблица ascii впервые появилась в AT&T UNIX Version 7.

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

Строчные и прописные символы отличаются только одним битом и ASCII символ 2 отличается от двойной кавычки тоже одним битом. Это сделано для облегчения механического кодирования символов или для использования клавиатур без микроконтроллеров, и такое pairing использовался на старых телетайпах.

Стандарт ASCII опубликован американским национальным институтом стандартов (USASI) в 1968 году.

## СМОТРИТЕ ТАКЖЕ
charsets(7), iso_8859-1(7), iso_8859-10(7), iso_8859-11(7), iso_8859-13(7), iso_8859-14(7), iso_8859-15(7), iso_8859-16(7), iso_8859-2(7), iso_8859-3(7), iso_8859-4(7), iso_8859-5(7), iso_8859-6(7), iso_8859-7(7), iso_8859-8(7), iso_8859-9(7), utf-8(7)


attributes

title: attributes(7)

summary: представления безопасности POSIX

text:
# attributes(7)

## ИМЯ
attributes - представления безопасности POSIX

## ОПИСАНИЕ
Замечание: Текст данной справочной страницы основан на материале раздела «POSIX Safety Concepts» руководства по библиотеки GNU C. Дополнительную информацию по темам, описанным здесь, можно найти в этом руководстве.

В справочных страницах по функциями есть раздел АТРИБУТЫ, в котором описано безопасен ли вызов функции в разных ситуациях. В этом разделе для функций описываются следующие отметки безопасности:

MT-Safe

Функции с MT-Safe или Thread-Safe безопасно вызывать при наличии других нитей. MT в MT-Safe означает Multi Thread.

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

Из-за оптимизации программы в целом, могут быть добавлены встраиваемые (inline) функции из библиотечного интерфейса, что может привести к небезопасному переупорядочиванию, и поэтому выполнение встраивания через интерфейс GNU C Library не рекомендуется. Задокументированное состояние MT-Safety не гарантируется при оптимизации программы в целом. Однако функции, определённые в видимых пользователю заголовках, разрабатывались как безопасные для встраивания.

MT-Unsafe

Функции, помеченные MT-Unsafe, небезопасно использовать в многонитевых программах.

Другие ключевые слова, встречающиеся в комментариях по безопасности, описаны в следующих разделах.

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

init

MT-Unsafe функции, помеченные init, выполняют MT-Unsafe инициализацию при первом их вызове.

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

race

MT-Safety функции, помеченные race, работают с объектами способами, которые могут привести к состязательности за данные или к подобному разрушающему параллельному выполнению. Это могут быть объекты, передаваемые в функции пользователями, возвращаемые функциями пользователю как значения или вообще не предоставляемые пользователям.

const

MT-Safety функции, помеченные const, не атомарно изменяют внутренние объекты, которые считаются константами, потому что существенная часть библиотеки GNU C обращается к ним без синхронизации. В отличие от MT-Unsafe функций с race, которые и читают, и изменяют внутренние объекты, const помечаются функции, производящие только запись. Вызов писателя остаётся MT-Unsafe, но тогда обязательная неизменяемость объектов, которые он изменил, позволяет читателям считаться MT-Safe (на время, пока не возникло других причин считаться небезопасными), так как отсутствие синхронизации не является проблемой, когда объекты в действительности константы.

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

sig

MT-Safety функции, помеченные sig, могут временно устанавливать обработчик сигнала для внутренних нужд, что может влиять на другие использования сигнала (указан после двоеточия).

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

term

MT-Safety функции, помеченные term, могут изменять настройки терминала рекомендуемым способом, а именно: вызывать tcgetattr(3), изменять некоторые флаги и затем вызывать tcsetattr(3), это создаёт интервал, в котором изменения, сделанные в других нитях, теряются. То есть функции, помеченные term, считаются MT-Unsafe.

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

### Другие отметки о безопасности
Функции могут помечаться другими ключевыми словами, показывающими возможности, которые не делают функции небезопасными для вызова, но может потребоваться учитывать это в определённых классах программ:

locale

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

Мы не помечаем эти функции как MT-Unsafe, однако, так как функции, которые изменяют объект локали, помечаются как const:locale и следовательно небезопасны. Считаясь небезопасными, последние не должны вызываться при выполнении нескольких нитей или включённых асинхронных сигналах, и поэтому локаль может считаться постоянной в этих контекстах, что делает первые функции безопасными.

env

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

Мы не помечаем эти функции как MT-Unsafe, однако, так как функции, которые изменяют окружение, помечаются как const:env и следовательно небезопасны. Считаясь небезопасными, последние не должны вызываться при выполнении нескольких нитей или включённых асинхронных сигналах, и поэтому окружение может считаться постоянным в этих контекстах, что делает первые функции безопасными.

hostid

MT-Safety функции, помеченные hostid, читают из системных структур данных, которые содержат «ID узла» машины. Эти структуры данных, обычно, нельзя изменить атомарно. Так как ожидается, что значение «ID узла», обычно не меняется, функция, читающая его (gethostid(3)), считается безопасной, но функция, изменяющая его (sethostid(3)), помечается const:hostid, что указывает на возможность специальной обращения при вызове. Этот конкретный случай специального обращения требует координации в масштабе всей системы (а не просто внутри процесса).

sigintr

MT-Safety функции, помеченные sigintr, обращаются к внутренней структуре данных _sigintr библиотеки GNU C без какой-либо защиты от одновременного изменения.

Мы не помечаем эти функции как MT-Unsafe, однако, так как функции, которые изменяют эту структуру данных, помечаются как const:sigintr и следовательно небезопасны. Считаясь небезопасными, последние не должны вызываться при выполнении нескольких нитей или включённых асинхронных сигналах, и поэтому структура данных может считаться постоянной в этих контекстах, что делает первые функции безопасными.

cwd

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

Этого недостаточно для пометки таких функций как MT-Unsafe, но когда такое поведение необязательно (например, nftw(3) с FTW_CHDIR), используйте полные пути или системные вызовы с файловыми дескрипторами (например, openat(2)).

:идентификатор

Иногда маркировки могут указываться после идентификаторов, они предназначены для некоторых групп функций, которые, например, обращаются к структурам данных небезопасным способом, как у race и const, или для предоставления более узкой информации, например имени сигнала, если функция помечена sig. В будущем предполагается применять это также к lock и corrupt.

В большинстве случаев идентификатор именуется по набору функций, но это может быть и имена глобальных объектов, аргументов функций, отличительные свойства или логические компоненты, связанные с ними, что выглядит как, например :buf(arg) — буфер, связанный с аргументом arg, или :tcattr(fd) — атрибуты терминала файлового дескриптора fd.

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

/условие

Некоторые описания безопасности могут быть условными, то есть они применяются только если логическое выражение, состоящее из вовлечённых аргументов, глобальных переменных или даже используемого ядра считается истинным. Например, /!ps и /one_per_line указывают, что впереди стоящий маркер применим только когда аргумент ps равен NULL или глобальная переменная one_per_line не равна нулю.

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

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


boot

title: boot(7)

text:
# boot(7)

## ИМЯ
boot - процесс запуска системы, основанный на UNIX System V Release 4

## ОПИСАНИЕ
Процесс запуска (или «последовательность запуска») варьируется в отдельных местах на разных системах, но в целом её можно разделить на несколько основных шагов, управляемых следующими компонентами:

1.

оборудование

2.

загрузчик операционной системы

3.

ядро

4.

начальный процесс пользовательского пространства (init и inittab)

5.

загрузочные сценарии

Далее следует их более подробное описание.

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

Эта программа, обычно, выполняет простейшие тесты компьютера и читает дополнительные из энергонезависимой памяти. Эта память в ПК реализована на базе памяти CMOS с питанием от батареи, и для краткости называется просто CMOS, хотя её официальное название вне мира ПК — NVRAM (nonvolatile RAM).

Параметры, хранящиеся в NVRAM, отличаются в разных системах, но как минимум, в ней хранится информация об устройстве с загрузчиком ОС или о порядке просмотра устройств; такое устройство называют загрузочным устройством. На аппаратной загрузочной стадии из постоянного места загрузочного устройства загружается загрузчик ОС, а затем ему передаётся управление.

Примечание:

Устройство, с которого может быть прочитан загрузчик ОС, может находиться в сети; в этом случае детали загрузки определяются протоколами типа DHCP, TFTP, PXE, Etherboot и т. п.

### Загрузчик ОС
Основной задачей загрузчика ОС является поиск ядра на некоем устройстве, загрузка его в память и запуск. Большинство загрузчиков ОС имеют интерактивный режим, позволяют указывать альтернативное ядро (резервное, если не заработает последнее собранное) и передавать ядру необязательные параметры.

В обычных ПК загрузчик ОС расположен в начальном 512-байтовом блоке загрузочного устройства — в так называемой главной загрузочной записи MBR (Master Boot Record).

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

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

В Linux системным загрузчиком ОС часто является программа lilo(8) или grub(8).

### Ядро
После загрузки ядро инициализирует различные компоненты компьютера и ОС; каждая часть ПО, ответственного за эту задачу, обычно, считается драйвером какого-то компонента. Ядро запускает процесс создания виртуальной памяти (это процесс ядра, в современных ядрах Linux называется «kswapd») и монтирует одну из файловых систем в качестве корневой (/).

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

Только после этого ядро создаёт первый пользовательский процесс PID (идентификатор процесса) которого равен 1. Обычно, этот процесс исполняет программу /sbin/init, передавая ей все оставшиеся параметры загрузки, не обработанные ядром.

### Корневой процесс пользовательского пространства
Примечание:

Дальнейшее описание применимо к ОС на основе UNIX System V Release 4. Однако, в некоторых широко используемых системах используется похожий, но существенно отличающийся подход, называемый systemd(1), процесс загрузки которого подробно описан в bootup(7).

При запуске /sbin/init считывается файл /etc/inittab для получения дальнейших инструкций. Этот файл определяет, что должно быть запущено, когда программа /sbin/init получит команду перейти на определённый уровень выполнения (run-level). Это позволяет администратору легко настроить окружение под какую-то задачу; для каждого уровня выполнения определён свой набор служб (например, S это однопользовательский (single-user) режим, на уровне 2 запускаются почти все сетевые службы).

Администратор может изменить текущий уровень выполнения с помощью init(1) и определить текущий уровень, используя runlevel(8).

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

### Загрузочные сценарии
Примечание:

Следующее описание применимо к системам, основанным на UNIX System V Release 4. Однако в некоторых широко используемых системах (Slackware Linux, FreeBSD, OpenBSD) используется немного другая схема загрузочных сценариев.

Для каждой управляемой службы (почтовой, сервера nfs, cron и т. п.) существует отдельный сценарий запуска в особом каталоге (/etc/init.d в большинстве версий Linux). Каждый из этих сценариев воспринимает в качестве отдельного аргумента слово «start» (вызывает запуск сценария) или слово «stop» (остановка службы). Сценарий может (необязательно) воспринимать и другие параметры (например, «restart» для остановки и запуска, «status» для отображения состояния службы и т. п.). Запуск сценария без параметров обычно покажет все возможные аргументы.

### Последовательность каталогов запуска
Для того, чтобы разные сценарии запускались/останавливались на разных уровнях выполнения в некотором, чётко определённом порядке, существует так называемая последовательность каталогов запуска. Это список каталогов, обычно /etc/rc[0-6S].d. В каждом из этих каталогов есть ссылки (обычно символические) на сценарии в каталоге /etc/init.d.

Первичный сценарий (обычно /etc/rc) вызывается из inittab(5); он запускает остальные сценарии служб через ссылки в соответствующих подкаталогах. Все ссылки с именами, начинающимися на 'S', вызываются с аргументом «start» (т. е. запускают службы). Все ссылки с именами, начинающимися на 'K', запускаются с аргументом «stop» (тем самым останавливая службу).

Для определения порядка запуска или остановки сценариев в одном уровне выполнения имена ссылок содержат порядковые номера. Также, для понимания смысла имён, они, обычно, заканчиваются на имя службы, которую они обслуживают. Например: ссылка /etc/rc2.d/S80sendmail запускает службу sendmail на уровне выполнения 2. Это случится после запуска /etc/rc2.d/S12syslog, но перед запуском /etc/rc2.d/S90xfs.

Через управление этими ссылками осуществляется управление порядком загрузки и уровнями выполнения; во многих системах существуют инструменты, помогающие в решении этой задачи (например, chkconfig(8)).

### Настройки загрузки
Программу, предоставляющую службу, часто называют демоном (daemon). Обычно, демоны могут воспринимать разные параметры командной строки и параметры. Для изменения таких параметров системным администраторам без редактирования текста сценария загрузки можно использовать отдельные файлы настроек. Они расположены в особом каталоге (обычно, /etc/sysconfig в старых системах Red Hat) и используются загрузочными сценариями.

В старых системах UNIX эти файлы содержали именно параметры командной строки демона, но в современных системах Linux (а также в HP-UX) эти файлы просто содержат разные переменные оболочки. Загрузочные сценарии в /etc/init.d читают и включают эти файлы настроек (то есть, выполняют команду sources для своего файла настройки) и после этого используют значения переменных.

## ФАЙЛЫ
/etc/init.d/, /etc/rc[S0-6].d/, /etc/sysconfig/

## СМОТРИТЕ ТАКЖЕ
init(1), systemd(1), inittab(5), bootparam(7), bootup(7), runlevel(8), shutdown(8)


bootparam

title: bootparam(7)

text:
# bootparam(7)

## ИМЯ
bootparam - аргументы, передаваемые ядру Linux во время загрузки

## ОПИСАНИЕ
При запуске ядру Linux могут быть переданы «аргументы командной строки», иначе говоря, «параметры загрузки». Как правило, они служат для передачи ядру информации о тех параметрах аппаратного обеспечения, которые оно не может определить, или для удаления/замены значений, используемых ядром.

Если ядро загружается непосредственно из BIOS, то возможности указать параметры нет. Для того, чтобы передать параметры ядру, необходимо использовать системный загрузчик, позволяющий это сделать, например GRUB.

### Список аргументов
Аргументы командной строки ядра преобразуются в список строк (параметров загрузки), разделённых пробелами. Большая часть аргументов имеет вид:

```
имя[=значение_1][,значение_2]…[,значение_10]
```

где «имя» — уникальное ключевое слово, используемое для определения части ядра, которой передаются указанные значения (если есть). Обратите внимание, что ограничение в 10 значений действительно существует, так как код, используемый в данный момент, обрабатывает только 10 разделённых запятой параметров на одно ключевое слово. Тем не менее, в особых случаях вы можете указать одно ключевое слово ещё раз, с помощью 10-и дополнительных параметров (если это позволяет функция настройки).

Большая часть обработки выполняется кодом из файла ядра init/main.c. Сначала ядро проверяет, является ли аргумент одним из специальных аргументов «root=», «nfsroot=», «nfsaddrs=», «ro», «rw», «debug» или «init». Назначение этих специальных аргументов объясняется ниже.

Затем производится проверка списка функций настройки: есть ли для заданного строкового параметра (например «foo») связанная с ним функция настройки («foo_setup()») для определённого устройства или части ядра. То есть, если вы передали ядру строку foo=3,4,5,6, то ядро проверит, зарегистрирован ли «foo» в массиве настроек. Если да, то будет вызвана соответствующая «foo» функция (foo_setup()), которой будут переданы аргументы 3, 4, 5 и 6, как указано в командной строке ядра.

Все параметры, указанные в виде «foo=bar» и не распознанные как обращения к функциям настройки (см. выше), считаются переменными окружения. Например, как аргумент загрузки можно указать «TERM=vt100».

Все остальные аргументы, не обработанные ядром и не считающиеся переменными окружения, затем будут переданы PID 1 (обычно, это программа init(1)). Наиболее часто встречающийся аргумент, передаваемый процессу init, — слово «single», указывающее, что система должна быть загружена в однопользовательском режиме, в котором не запускаются какие-либо службы. Более подробная информация об аргументах приведена в руководстве по установленной в системе версии init(1).

### Общие аргументы загрузки, не относящиеся к настройке устройств
«init=…»

Задаёт начальную команду, запускаемую ядром. Если этот параметр не задан или программа не найдена, то ядро попробует запустить /sbin/init, затем /etc/init, затем /bin/init, затем /bin/sh. Если не удалось запустить ни одну из указанных программ, то ядро переходит в режим «паники».

«nfsaddrs=…»

Задаёт адрес загрузки с NFS. Используется при загрузке системы по сети.

«nfsroot=…»

Задаёт корневую файловую систему NFS. Если эта строка не начинается с «/», «,» или цифры, то перед ним будет вставлена строка «/tftpboot/». Этот параметр используется при загрузке системы по сети.

«root=…»

Этот аргумент указывает ядру, какое устройство должно быть использовано в качестве корневой файловой системы. Значение по умолчанию этого параметра устанавливается при сборке ядра и, как правило, совпадает с устройством, на котором была расположена корневая файловая система во время сборки. Для использования в качестве устройства с корневой файловой системой, к примеру, второго дисковода, следует указать «root=/dev/fd1».

Корневое устройство может быть указано как в символьном, так и в числовом виде. Символьное представление имеет вид /dev/XXYN, где XX означает тип устройства (например, «hd» — для совместимых с ST-506 жёстких дисков, при этом Y принимает значения от «a» до «d»; «sd» — для совместимых со SCSI дисков, при этом Y принимает значения от «a» до «e»), Y — буква или номер устройства, а N — номер (в десятичной системе счисления) раздела на этом устройстве.

Заметим, что в данном случае речь не идёт о конкретном назначении этих устройств в файловой системе. Приставка «/dev/» — это всего лишь дань соглашениям.

Также применяется менее удобный и менее совместимый способ указания устройств с помощью чисел в формате «старший/младший номер» (например, старший номер /dev/sda3 равен 8, младший равен 3, и устройство можно указать как «root=0x803»).

'rootdelay='

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

'rootflags=...'

В этом параметре указывается строка параметров монтирования корневой файловой системы (смотрите также fstab(5)).

'rootfstype=...'

Параметр «rootfstype» указывает ядру смонтировать корневую файловую систему, как если бы она была задаваемого типа. Это может быть полезно (как пример) при монтировании файловой системы ext3 как ext2 и затем удалении журнала в корневой файловой системе, что, фактически, превращает ext3 в ext2 и для этого не нужно загружать машину с другого носителя.

«ro» и «rw»

Параметр «ro» указывает ядру монтировать корневую файловую систему «только для чтения» для того, чтобы программа проверки целостности файловой системы (fsck) могла работать с не изменяющейся файловой системой. Ни один процесс не может записать данные в файл, находящийся в данной файловой системе до тех пор, пока она не будет «перемонтирована» для чтения/записи, например, командой «mount -w -n -o remount /» (см. также mount(8)).

Параметр «rw» указывает ядру монтировать корневую файловую систему в режиме для чтения/записи. Он используется по умолчанию.

'resume=...'

Указывает ядру где расположены данные suspend-to-disk, которые вы хотите использовать для возобновления работы машины при выходе из состояния сна. Обычно совпадает с расположение раздела или файла подкачки. Пример:

```
resume=/dev/hda2

```

«reserve=…»

Этот параметр используется для защиты от тестирования определённых областей ввода/вывода. Команда должна быть задана в следующем виде:

```
reserve=iobase,extent[,iobase,extent]...

```

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

Данный параметр загрузки служит для указания определённой области портов ввода/вывода, которую не нужно тестировать. Драйвер устройства не будет проверять указанную область, если только другой параметр явно не указывает на необходимость их проверки.

Например, загрузочная строка

```
reserve=0x300,32  blah=0x300

```

предотвращает проверку адресов 0x300-0x31f всеми драйверами устройств, кроме «blah».

«panic=N»

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

```
echo N > /proc/sys/kernel/panic

```

«reboot=[warm|cold][,[bios|hard]]»

Начиная Linux 2.0.22 по умолчанию используется «холодная» (cold) перезагрузка. Возможно вернуть старое значение (warm) по умолчанию с помощью «reboot=warm» («холодная» перезагрузка может понадобиться для сброса аппаратного обеспечения, однако, она может уничтожить данные дискового кэша. «Теплая» перезагрузка может быть несколько быстрее). По умолчанию перезагрузка производится аппаратными (hard) средствами, а именно запросом контроллеру клавиатуры команды на установку низкого уровня линии сброса. Однако точно существует, по меньшей мере, один тип материнских плат, на которых этот способ не работает. При указании параметра «reboot=bios» перезагрузка будет осуществляться путем перехода в BIOS.

«nosmp» и «maxcpus=N»

(Только, если определён __SMP__.) Параметры загрузки «nosmp» или «maxcpus=0» полностью отключают SMP. Аргумент «maxcpus=N» ограничивает количество процессоров, активируемых в режиме SMP, значением N.

### Аргументы загрузки, используемые разработчиками ядра
«debug»

Сообщения ядра обрабатываются демоном (например, klogd(8) или подобным), что позволяет записывать их на диск. Сообщения с приоритетом выше console_loglevel выводятся также и на консоль (список приоритетов смотрите в syslog(2)). По умолчанию, значение console_loglevel устанавливается для протоколирования сообщений на уровень выше чем KERN_DEBUG. Этот загрузочный параметр указывает ядру также выводить сообщения приоритета KERN_DEBUG. Уровень журнала для консоли также может быть установлен во время работы через файл /proc/sys/kernel/printk (описан в syslog(2)), операцией SYSLOG_ACTION_CONSOLE_LEVEL в syslog(2) или dmesg(8).

«profile=N»

Существует возможность включить функцию оценки быстродействия ядра (kernel profiling). Для этого необходимо присвоить ненулевое значение переменной prof_shift. Это может быть сделано либо установкой параметра CONFIG_PROFILE при сборке ядра, либо указанием параметра «profile=N». Значение переменной prof_shift устанавливается равным N, или CONFIG_PROFILE или по умолчанию равняется 2. Оно определяет степень детализации оценки: если система исполняет код ядра, то с каждым тиком показания счётчика будут увеличиваться:

```
profile[address >> prof_shift]++;

```

Необработанную информацию оценки можно прочитать из /proc/profile. Для удобства чтения можно воспользоваться какой-либо утилитой, например, readprofile.c. Запись в /proc/profile приведёт к сбросу показаний счётчиков.

### Аргументы загрузки для использования ramdisk
(Только, если ядро было собрано с CONFIG_BLK_DEV_RAM) В общем, использовать ram-диск под Linux — плохая идея, так как ядро использует доступную память гораздо эффективнее. Однако при загрузке часто удобней копировать содержимое дискеты на ramдиск. Также, это позволяет получить систему, в которой загрузка отдельных модулей (для файловых систем или оборудования) производится до получения доступа к основной файловой системе.

В Linux 1.3.48 работа с ramdisk была значительно изменена. Раньше память выделялась статически и существовал параметр «ramdisk=N», определявший её размер. Также возможно было задать необходимый размер во время сборки ядра. В настоящее время под ram-диски используются буферный кэш, размер которого изменяется динамически. Дополнительную информацию по текущем настройкам ramdisk можно найти в файле исходного кода ядра Documentation/blockdev/ramdisk.txt (в старых ядрах — Documentation/ramdisk.txt).

Существует четыре параметра: два логических и два целочисленных.

«load_ramdisk=N»

Если N=1, то выполнять загрузку ram-диска. Если N=0, то ramdisk не загружается (по умолчанию 0).

«prompt_ramdisk=N»

Если N=1, то запрашивать вставку дискеты (по умолчанию). Если N=0, то не запрашивать (таким образом, этот параметр вообще не нужен).

«ramdisk_size=N» или «ramdisk=N» (устарел)

Установить предельный размер ram-диска(-ов) равным N КБ. По умолчанию 4096 (4 МБ).

«ramdisk_start=N»

Установить номер начального блока (смещение на дискете, с которого начинается ram-диск) равным N. Этот параметр не требуется, если ram-диск находится сразу за образом ядра.

«noinitrd»

(Только, если ядро было собрано с CONFIG_BLK_DEV_RAM и CONFIG_BLK_DEV_INITRD). В настоящее время существует возможность собрать ядро с поддержкой initrd. Если эта возможность включена, то при запуске загружается ядро и начальный ram-диск. Затем ядро преобразует initrd в «обычный» ram-диск, который монтируется в качестве корневой файловой системы на чтение-запись. Далее запускается /linuxrc. Затем монтируется «настоящая» корневая файловая система, а файловая система initrd переносится в //initrd. И, наконец, начинается обычная процедура загрузки (например, запускается /sbin/init).

Более подробно свойство initrd описано в файле исходного кода ядра Documentation/admin-guide/initrd.rst (или в Documentation/initrd.txt до Linux 4.10).

Параметр «noinitrd» указывает ядру пропускать вышеуказанные шаги, несмотря на то, что оно было собрано с поддержкой initrd. Данные initrd, тем не менее, остаются в /dev/initrd (это устройство может быть использовано только один раз: после того, как последний процесс, использующий /dev/initrd, завершится, данные освобождаются).

### Параметры загрузки для SCSI-устройств
Общие соглашения для этого раздела:

iobase — первый порт ввода/вывода, занятый узлом SCSI. Порты указываются в шестнадцатеричной системе счисления, обычно их значения находятся в диапазоне от 0x200 до 0x3ff.

irq — аппаратное прерывание, настроенное для карты. Возможные значения зависят от карты, но обычно используются 5, 7, 9, 10, 11, 12 и 15. Остальные значения, как правило, используются общей периферией, такой как: жёсткие диски IDE, дисководы, последовательные порты и т. д.

scsi-id — ID, используемый узел-адаптером для своей идентификации на шине SCSI. Только некоторые адаптеры позволяют изменять это значение, у большинства оно фиксировано. Обычно, в качестве значения используется 7, однако, карты Seagate и Future Domain TMC-950 используют 6.

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

«max_scsi_luns=…»

Устройство SCSI может включать в себя «подустройства». В качестве примера можно взять новые многодисковые SCSI CD-ROM-ы. Адрес каждого места под компакт-диск может быть задан «логическим номером устройства» (Logical Unit Number — LUN). Но большинство устройств, таких как, жёсткие диски, ленточные накопители и др., содержат только одно устройство, которому присваивается нулевой LUN.

Некоторые плохо спроектированные устройства SCSI не обрабатывают запросы для LUN, не равные нулю. Поэтому, новые ядра, если при сборке ядра не был установлен флаг CONFIG_SCSI_MULTI_LUN, по умолчанию будут опрашивать только устройства с LUN, равным нулю.

Для указания количества проверяемых при загрузке LUN можно в качестве параметра загрузки указать «max_scsi_luns=n», где n является числом от одного до восьми. Для избежания вышеописанной проблемы можно указать, что n=1.

Hастройка ленточных накопителей SCSI

С помощью приведённой ниже строки загрузочных параметров можно настроить драйвер ленточных накопителей SCSI:

```
st=buf_size[,write_threshold[,max_bufs]]

```

Первые два числа указываются в килобайтах. По умолчанию значение buf_size равно 32k Б, а максимальный размер, который может быть указан, — 16384 КБ. В write_threshold задаётся значение, при достижении которого содержимое буфера записывается на ленту (по умолчанию равно 30 КБ). Максимальное количество буферов (max_bufs) зависит от количество обнаруженных накопителей. По умолчанию используется два буфера. Пример использования этого параметра:

```
st=32,30,2

```

Более подробная информация приведена в файле Documentation/scsi/st.txt (или drivers/scsi/README.st — в старых ядрах), находящемся в дереве исходного кода ядра Linux.

### Жёсткие диски
Параметры драйвера IDE-диска/CD-ROM

Драйвер IDE понимает довольно большое число параметров, начиная от указания геометрии диска до поддержки неисправных микросхем контроллера. Параметры, относящиеся к конкретному диску, указываются с помощью «hdX=», где X принимает значения от «a» до «h».

Общие для всех дисков параметры указываются с префиксом «hd=». Заметим, что их можно использовать и для какого-то конкретного диска, и при этом параметр будет применён именно так, как ожидалось.

Также заметим, что «hd=» может быть использован для ссылки на следующий неуказанный диск в последовательности (a, …, h) В дальнейшем, для краткости, параметры будут описаны в виде «hd=». Более подробная информация приведена в файле Documentation/ide/ide.txt (в старых ядрах — Documentation/ide.txt или в совсем старых — drivers/block/README.ide) из дерева исходного кода ядра Linux.

Параметры «hd=cyls,heads,sects[,wpcom[,irq]]»

Эти параметры используются для указания физической структуры диска. Обязательными являются только первые три значения. Значения цилиндров(cyls)/головок(heads)/секторов(sects) в дальнейшем используются в программе fdisk. Значение предварительной компенсации записи (wpcom) для дисков IDE игнорируется. Значение IRQ, указанное в качестве irq, используется в контроллере интерфейса, к которому подключён диск, и, на самом деле, не относится к диску.

Параметр «hd=serialize»

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

Параметр «hd=noprobe»

Не определять этот диск. Например,

```
hdb=noprobe hdb=1166,7,17

```

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

Параметр «hd=nowerr»

Бит WRERR_STAT на некоторых дисках установлен постоянно. Этот параметр позволяет обойти эту проблему в таких устройствах.

Параметр «hd=cdrom»

Указывает драйверу IDE, что вместо обычного жёсткого диска IDE подключён CD-ROM, совместимый с ATAPI. В большинстве случаев CD-ROM определяется автоматически, однако, если этого не происходит, можно воспользоваться данным параметром.

Стандартные параметры драйвера дисков ST-506 («hd=»)

Стандартный драйвер дисков, также как драйвер IDE, понимает аргументы, описывающие структуру дисков. Однако он ожидает указания только трёх значений (C/H/S), а если их будет больше или меньше, то просто проигнорирует их. Кроме того, аргумент должен быть указан в виде «hd=», то есть «hda=» и т. п., в данном случае, являются неправильным. Формат следующий:

```
hd=cyls,heads,sects

```

Если установлено два диска, то для второго диска нужно повторить вышеуказанную строку со структурой.

### Устройства Ethernet
Различные драйверы используют разные параметры, но все они, как минимум, распознают IRQ, базу ввода/вывода и имя. В общей форме выглядит это примерно так:

```
ether=irq,iobase[,param_1[,...param_8]],name
```

Первый не числовой аргумент воспринимается как имя. Значения param_n (если есть) у разных карт/драйверов, обычно, имеют различный смысл. Обычно, значения param_n используются для указания адреса общей памяти, выбранного интерфейса, канала DMA и т. п.

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

```
ether=0,0,eth1
```

Обратите внимание, что ноль в качестве значения IRQ и базы ввода/вывода указывает драйверам определять значения автоматически.

Исчерпывающей документацией по использованию нескольких карт и по специфичным для карты/драйвера значениям param_n можно считать Ethernet-HowTo. Желающие могут обратиться к соответствующему их карте разделу этого документа.

### Драйвер дисковода
У драйвера дисковода есть много параметров. Все они перечислены в файле Documentation/blockdev/floppy.txt (в старых ядрах — Documentation/floppy.txt или в совсем старых ядрах — drivers/block/README.fd) из дерева исходного кода ядра Linux. Дополнительную информацию ищите в этом файле.

### Драйвер звука
Драйвер звука также может учитывать параметры загрузки для замены встроенных при компиляции значений по умолчанию. Не рекомендуется заново определять значение параметров, так как это довольно сложно. Описание находится в файле Documentation/sound/oss/README.OSS (и в drivers/sound/Readme.linux у старых ядер) в дереве исходного кода ядра Linux. Параметр загрузки имеет следующий вид:

```
sound=device1[,device2[,device3...[,device10]]]
```

где каждое значение устройства N имеет формат 0xTaaaId, байты которого используются следующим образом:

T — тип устройства: 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16, 7=SB16-MPU401

aaa — адрес ввода/вывода в шестнадцатеричном виде.

I — линия прерывания в шестнадцатеричном виде (т. е. 10=a, 11=b, …)

d — канал DMA.

Как видите, результат довольно непонятен, поэтому лучше установить собственные значения при компиляции. Параметр загрузки «sound=0» полностью отключит драйвер звука.

### Драйвер принтера
«lp=»

Синтаксис:

```
lp=0
lp=auto
lp=reset
lp=port[,port...]

```

Вы можете указать драйверу принтера, какие порты надо использовать, а какие не использовать совсем. Это удобно, если не нужно, чтобы драйвер принтера захватывал все доступные параллельные порты, и оставлял их другим драйверам (таким, как PLIP, PPA).

В значении перечисляется несколько названий портов. Например, при lp=none,parport0 используется первый параллельный порт для lp1 и отключается lp0. Чтобы вообще отключить драйвер принтера, укажите lp=0.

## СМОТРИТЕ ТАКЖЕ
klogd(8), mount(8)

Актуальную информацию можно найти в файле исходного кода ядра Documentation/admin-guide/kernel-parameters.txt.