cciss

package: man-pages-ru

title: cciss(4)

text:
# cciss(4)

## ИМЯ
cciss - блочный драйвер устройства HP Smart Array

## ОБЗОР

```
modprobe cciss [ cciss_allow_hpsa=1 ]
```

## ОПИСАНИЕ
Замечание: Данный устаревший драйвер был удалён из ядра версии 4.14; в новых ядрах его заменяет hpsa(4).

cciss — это блочный драйвер для старых контроллеров RAID HP Smart Array.

### Параметры
cciss_allow_hpsa=1: этот параметр запрещает драйверу cciss пробовать управлять контроллерами, которыми может управлять драйвер hpsa(4). Другими словами, этим параметром драйвер cciss будет ограничен следующими контроллерами:

```
    Smart Array 5300

    Smart Array 5i

    Smart Array 532

    Smart Array 5312

    Smart Array 641

    Smart Array 642

    Smart Array 6400

    Smart Array 6400 EM

    Smart Array 6i

    Smart Array P600

    Smart Array P400i

    Smart Array E200i

    Smart Array E200

    Smart Array E200i

    Smart Array E200i

    Smart Array E200i

    Smart Array E500
```

### Поддерживаемое оборудование
Драйвер cciss поддерживает следующие платы Smart Array:

```
    Smart Array 5300

    Smart Array 5i

    Smart Array 532

    Smart Array 5312

    Smart Array 641

    Smart Array 642

    Smart Array 6400

    Smart Array 6400 U320 Expansion Module

    Smart Array 6i

    Smart Array P600

    Smart Array P800

    Smart Array E400

    Smart Array P400i

    Smart Array E200

    Smart Array E200i

    Smart Array E500

    Smart Array P700m

    Smart Array P212

    Smart Array P410

    Smart Array P410i

    Smart Array P411

    Smart Array P812

    Smart Array P712m

    Smart Array P711m
```

### Особенности настройки
Для настройки контроллеров HP Smart Array используйте HP Array Configuration Utility (hpacuxe(8) или hpacucli(8)) или Offline ROM-based Configuration Utility (ORCA), которую можно запустить из ROM Smart Array при включении машины.

## ФАЙЛЫ

### Узлы устройства
Ниже приведена схема именования устройств:

```
Старшие номера:
```

```
    104     cciss0

    105     cciss1

    106     cciss2

    105     cciss3

    108     cciss4

    109     cciss5

    110     cciss6

    111     cciss7
```

```
Младшие номера:
```

```
    b7 b6 b5 b4 b3 b2 b1 b0

    |----+----| |----+----|

         |           |

         |           +-------- Идентификатор раздела (0=всё устройство,

                                                      1-15 раздел)

         |

         +-------------------- Номер логического тома
```

```
Порядок именования устройств:
```

```
    /dev/cciss/c0d0         Контроллер 0, диск 0, устройство целиком

    /dev/cciss/c0d0p1       Контроллер 0, диск 0, раздел 1

    /dev/cciss/c0d0p2       Контроллер 0, диск 0, раздел 2

    /dev/cciss/c0d0p3       Контроллер 0, диск 0, раздел 3
```

```
    /dev/cciss/c1d1         Контроллер 1, диск 1, устройство целиком

    /dev/cciss/c1d1p1       Контроллер 1, диск 1, раздел 1

    /dev/cciss/c1d1p2       Контроллер 1, диск 1, раздел 2

    /dev/cciss/c1d1p3       Контроллер 1, диск 1, раздел 3
```

### Файлы в /proc
В файлах /proc/driver/cciss/cciss[0-9]+ содержится информация о настройке каждого контроллера. Пример:

```
$ cd /proc/driver/cciss
$ ls -l
total 0
-rw-r--r-- 1 root root 0 2010-09-10 10:38 cciss0
-rw-r--r-- 1 root root 0 2010-09-10 10:38 cciss1
-rw-r--r-- 1 root root 0 2010-09-10 10:38 cciss2
$ cat cciss2
cciss2: HP Smart Array P800 Controller
Board ID: 0x3223103c
Firmware Version: 7.14
IRQ: 16
Logical drives: 1
Current Q depth: 0
Current # commands on controller: 0
Max Q depth since init: 1
Max # commands on controller since init: 2
Max SG entries since init: 32
Sequential access devices: 0
cciss/c2d0:   36.38GB       RAID 0
```

### Файлы в /sys
/sys/bus/pci/devices/<dev>/ccissX/cXdY/model

Модель логического устройства Y контроллера X со страницы 0 SCSI INQUIRY.

/sys/bus/pci/devices/<dev>/ccissX/cXdY/rev

Версия логического устройства Y контроллера X со страницы 0 SCSI INQUIRY.

/sys/bus/pci/devices/<dev>/ccissX/cXdY/unique_id

Серийный номер логического устройства Y контроллера X со страницы 83 SCSI INQUIRY.

/sys/bus/pci/devices/<dev>/ccissX/cXdY/vendor

Производитель логического устройства Y контроллера X со страницы 0 SCSI INQUIRY.

/sys/bus/pci/devices/<dev>/ccissX/cXdY/block:cciss!cXdY

Символьная ссылка на /sys/block/cciss!cXdY.

/sys/bus/pci/devices/<dev>/ccissX/rescan

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

/sys/bus/pci/devices/<dev>/ccissX/resettable

Значение 1 в файле показывает, что параметр ядра «reset_devices=1» (используемый kdump) был принят данным контроллером. Значение 0 показывает, что параметр ядра «reset_devices=1» принят не был. Некоторые модели Smart Array не способны принять этот параметр.

/sys/bus/pci/devices/<dev>/ccissX/cXdY/lunid

8-байтовый LUN ID, используемый для адресации логического устройства Y контроллера X.

/sys/bus/pci/devices/<dev>/ccissX/cXdY/raid_level

Уровень RAID логического устройства Y контроллера X.

/sys/bus/pci/devices/<dev>/ccissX/cXdY/usage_count

Счётчик использования (число открытий) логического устройства Y контроллера X.

### Поддержка ленточных устройств SCSI и устройств смены носителя
Драйвер поддерживает устройства SCSI с последовательным доступом и смены носителя, и автоматически создаёт соответствующие узлы устройств (например, /dev/st0, /dev/st1 и т. д.; подробней смотрите в st(4)). Чтобы использовать ленточные устройства SCSI с контроллером Smart Array 5xxx в настройках ядра нужно включить «SCSI tape drive support for Smart Array 5xxx» и «SCSI support».

Также заметим, что драйвер не привлекает ядро SCSI во время инициализации. Драйвер должен динамически задействовать ядро SCSI через запись в файловой системе /proc, которую (/proc/driver/cciss/cciss*) «блочная» часть драйвера создаёт во время работы. Так сделано потому, что на момент инициализации драйвера ядро SCSI ещё может быть не инициализировано (так как драйвер — блочный) и попытка зарегистрировать его в ядре SCSI в этом случае вызывала бы зависание. Это лучше всего выполнять из сценария инициализации (обычно, в /etc/init.d, но в разных дистрибутивах по-разному). Пример:

```
for x in /proc/driver/cciss/cciss[0-9]*
do

    echo "engage scsi" > $x
done
```

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

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

### Ленточные устройства SCSI, подключаемые во время работы (hot plug)
Поддерживается подключение ленточных устройств SCSI без выключения машины. Драйвер cciss должен быть уведомлён об изменениях на шине SCSI. Это можно сделать через файловую систему /proc. Пример:

echo "rescan" > /proc/scsi/cciss0/1

Это заставляет драйвер:

1.

Опросить адаптер об изменениях на физических шинах SCSI и/или управляемой петли (arbitrated loop) fibre channel;

2.

Определить все новые или удалённые устройства с последовательным доступом или смены носителя;

Драйвер выводит сообщения о добавленных или удалённых устройствах, а также контроллер, шину, назначение и lun каждого используемого устройства. Также, драйвер уведомляет промежуточный слой SCSI об этих изменениях.

Заметим, что по соглашению об именовании кроме имени драйвера, записи файловой системы /proc содержат номер (например, «cciss0» вместо «cciss», как вы могли бы ожидать).

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

### Обработка ошибок SCSI для ленточных устройств и устройств смены носителя
Промежуточный слой Linux SCSI предоставляет порядок (protocol) обработки ошибок, который запускается, если команда SCSI выполнилась с ошибкой определённое количество раз (которое может зависеть от команды). Драйвер cciss следует этому порядку с некоторыми изменениями. Обычный порядок состоит из четырёх шагов:

- Устройству указывается прервать работу команды.

- Если это не сработало, устройство сбрасывается (reset).

- Если это не сработало, сбрасывается шина SCSI.

- Если это не сработало, сбрасывается адаптер шины узла.

Как драйвер SCSI, cciss является блочным и только ленточные устройства и устройства смены носителя представлены на промежуточном уровне SCSI. Кроме этого, в отличие от более простых драйверов SCSI, дисковый ввод-вывод продолжается через блочную часть во время процесса восстановления после ошибки SCSI. Поэтому драйвер cciss выполняет только первые два шага: прерывание команды и сброс устройства. Также заметим, что большинству ленточных устройств не поможет прерывание команды и, иногда, они даже не подчиняются этой команде, хотя очень редко. Если команда не может быть прервана и устройство не может быть сброшено, то устройство переводится в неактивный режим (offline).

Если событие обработки ошибок возникло и ленточное устройство успешно сброшено или последняя команда успешно прервана, то ленточное устройств может всё ещё продолжать не позволять выполнять ввод-вывод, пока какая-нибудь команда не поместит ленточное устройство в известное положение. Как правило, вы должны перемотать ленту (например, командной mt -f /dev/st0 rewind) перед тем как продолжить ввод-вывод снова в ленточное устройство, которое было сброшено.

## СМОТРИТЕ ТАКЖЕ
hpsa(4), cciss_vol_status(8), hpacucli(8), hpacuxe(8)

http://cciss.sf.net, Documentation/blockdev/cciss.txt и файл Documentation/ABI/testing/sysfs-bus-pci-devices-cciss в дереве исходного кода ядра Linux


title: console_codes(4)

text:
# console_codes(4)

## ИМЯ
console_codes - управляющие и экранирующие последовательности консоли Linux

## ОПИСАНИЕ
Консоль Linux имеет большой набор средств управления терминалами VT102 и ECMA-48/ISO 6429/ANSI X364, а также некоторым количеством индивидуальных последовательностей для изменения цветовой палитры, перекодировки символьного набора и т. д. В таблицах, приведенных ниже (во втором столбце), указывается мнемонический код ECMA-48 или DEC (если последнее приписано к DEC) данной функции. Последовательности без мнемонического кода не принадлежат ни к ECMA-48, ни к VT102.

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

Если консоль работает в режиме UTF-8, то входящие байты сначала организуются в 16-битовый Юникод. В ином случае каждый байт преобразуется согласно текущей таблице перекодировки (которая переводит данные в Юникод). Смотри раздел Наборы символов ниже).

Обычно значения Юникода преобразуются в индекс шрифта, который хранится в видеопамяти таким образом, что соответствующий образ (обнаруженный в видео-ПЗУ) появляется на экране. Заметим, что работа с Юникодом (и текущими аппаратными средствами компьютеров) позволяет одновременно использовать только 512 различных образов.

Если текущим значением Юникода является управляющий символ или если в данный момент обрабатывается экранирующая последовательность, значение будет обрабатываться особым образом. Вместо того, чтобы значение было преобразовало в шрифт и отобразилось как образ, оно приведёт к выполнению определённого действия (например, перемещение курсора) или другой функции управления. Смотрите ниже раздел Управление консолью Linux.

Некорректно явно указывать в программах аппаратные последовательности управление терминалом. Linux поддерживает работу с базой возможностей терминала terminfo(5). Вместо того, чтобы вводить управляющие последовательности вручную, вы, наверняка, захотите использовать для этой работы библиотеку, использующую terminfo, или другие утилиты, такие как ncurses(3), tput(1) или reset(1).

### Управление консолью Linux
Этот раздел описывает все управляющие символы и экранирущие последовательности, которые выполняют специальные команды (т.е., всё, что отличается от простого вывода символа в текущую позицию курсора) консоли Linux.

Управляющие символы

Символ считается управляющим, если (до преобразования согласно таблице перекодировки) он содержит один из 4 кодов: 00 (NUL), 07 (BEL), 08 (BS), 09 (HT), 0a (LF), 0b (VT), 0c (FF), 0d (CR), 0e (SO), 0f (SI), 18 (CAN), 1a (SUB), 1b (ESC), 7f (DEL). Можно установить режим "показывать управляющие символы" (см. ниже), при этом символы 07, 09, 0b, 18, 1a, 7f будут выводиться на экран в виде образов. С другой стороны, в режиме UTF-8 все коды с 00 по 1f воспринимаются как управляющие символы, независимо от режима «показа управляющих символов».

Если встречается управляющий символ, то он учитывается немедленно, и никак не влияет в дальнейшем (даже если он стоял в середине экранирующей последовательности), и управляющая последовательность продолжается со следующего символа. Однако, символ ESC, начинающий новую экранирующую последовательность, возможно, отменит незаконченную предыдущую последовательность, а символы CAN и SUB точно закончат любую экранирующую последовательность. Распознаваемыми управляющими символами являются: BEL, BS, HT, LF, VT, FF, CR, SO, SI, CAN, SUB, ESC, DEL, CSI. Они выполняют стандартные для них действия:

BEL (0x07, ^G) издает звуковой сигнал;

BS (0x08, ^H) удаляет предыдущий символ (смещается влево на один столбец, но не далее, чем за начало строки);

HT (0x09, ^I) перемещается на следующую позицию табуляции или в конец строки, если до этого не было установлено позиций табуляции;

LF (0x0A, ^J), VT (0x0B, ^K) и FF (0x0C, ^L) задают перевод строки, а LF/NL (в режиме новой строки) выполняет перевод каретки;

CR (0x0D, ^M) задает перевод каретки;

SO (0x0E, ^N) приводит в действие набор символов G1;

SI (0x0F, ^O) приводит в действие набор символов G0;

CAN (0x18, ^X) и SUB (0x1A, ^Z) прерывают экранирующую последовательность;

ESC (0x1B, ^[) начинают экранирующую последовательность;

DEL (0x7F) игнорируется;

CSI (0x9B) эквивалентно ESC [.

ESC- но не CSI-последовательности

ESC c

RIS

Сброс

ESC D

IND

Перевод строки

ESC E

NEL

Новая строка

ESC H

HTS

Установить позицию табуляции в текущем столбце

ESC M

RI

Обратный перевод строки

ESC Z

DECID

Есть только у DEC. Ядро возвращает строку ESC [ ? 6 c, утверждая что это VT102.

ESC 7

DECSC

Сохранить текущее состояние (координаты курсора, атрибуты, наборы символов, указанные G0, G1).

ESC 8

DECRC

Восстановить последнее сохранённое ESC 7 состояние

ESC [

CSI

Начало управляющей последовательности

ESC %

Начать последовательность с выбором набора символов

ESC % @

выбор по умолчанию (ISO 646/ISO 8859-1)

ESC % G

выбор UTF-8

ESC % 8

выбор UTF-8 (устарело)

ESC # 8

DECALN

Экранный тест на выравнивание DEC: заполняет экран символами E

ESC (

Начать последовательность с выбором набора символов G0

ESC ( B

выбор по умолчанию (таблица перекодировки ISO 8859-1)

ESC ( 0

выбор графической перекодировки VT100

ESC ( U

выбрать null-перекодировку — сразу в символьную ROM

ESC ( K

пользовательская перекодировка — карта

загружается утилитой mapscrn(8)

ESC )

Начать последовательность с выбором набора символов G1

(следом идёт один из символов B, 0, U, K, как с G0)

ESC >

DECPNM

Установить режим ввода цифр для дополнительной клавиатуры

ESC =

DECPAM

Установить режим управления для дополнительной клавиатуры

ESC ]

OSC

(Должно быть: команда операционной системы) ESC ] P nrrggbb: задать палитру, в параметре указывается 7 шестнадцатеричных цифр после последнего P :-(. Здесь n определяет цвет (0–15), а в rrggbb указываются значения красного/зелёного/синего (0–255) ESC ] R: сбросить палитру

CSI-последовательности ECMA-48

CSI (или ESC [) сопровождаются последовательностью параметров, являющихся десятичными номерами, разделёнными точкой с запятой (самый больший из них — NPAR (16)). Пустой или отсутствующий параметр приравнивается нулю. Последовательность параметров может начинаться одним знаком вопроса.

Тем не менее, после CSI [ (или ESC [ [) считывается единственный символ и оставшаяся часть последовательности игнорируется. (Смысл этого в том, чтобы не отображать функциональную клавишу).

Результат работы CSI-последовательности определяется её конечным символом.

@

ICH

Вставить N пустых символов

A

CUU

Переместить курсор вверх на N строк

B

CUD

Переместить курсор вниз на N строк

C

CUF

Переместить курсор вправо на N столбцов

D

CUB

Переместить курсор влево на N столбцов

E

CNL

Переместить курсор вниз на N строк в столбец 1

F

CPL

Переместить курсор вверх на N строк в столбец 1

G

CHA

Переместить курсор в указанный столбец текущей строки

H

CUP

Переместить курсор в указанную строку и столбец (начало в 1,1)

J

ED

Очистить экран (по умолчанию от курсора до конца экрана)

ESC [ 1 J: очистить от начала до курсора

ESC [ 2 J: очистить весь экран

ESC [ 3 J: очистить весь экран, включая буфер

обратной прокрутки (начиная с Linux 3.0)

K

EL

Очистить строку (по умолчанию от курсора до конца строки)

ESC [ 1 K: очистить от начала строки до курсора

ESC [ 2 K: очистить всю строку

L

IL

Вставить N пустых строк

M

DL

Удалить N строк

P

DCH

Удалить N символов в текущей строке

X

ECH

Очистить N символов в текущей строке

a

HPR

Переместить курсор вправо на N столбцов

c

DA

Ответ по ESC [ ? 6 c: «Я терминал VT102»

d

VPA

Переместить курсор в указанную строку текущего столбца

e

VPR

Переместить курсор вниз на N строк

f

HVP

Переместить курсор в указанную строку и столбец

g

TBC

Без параметра: очистить текущую позицию табуляции

ESC [ 3 g: удалить все позиции табуляции

h

SM

Режим установки (смотрите ниже)

l

RM

Режим сброса (смотрите ниже)

m

SGR

Установка атрибутов (смотрите ниже)

n

DSR

Отчёт о состоянии (смотрите ниже)

q

DECLL

Управление индикаторами на клавиатуре

ESC [ 0 q: выключить все индикаторы

ESC [ 1 q: включить Scroll Lock

ESC [ 2 q: включить Num Lock

ESC [ 3 q: включить Caps Lock

r

DECSTBM

Установить область прокрутки; параметрами будут верхняя и нижняя строки

s

?

Сохранить местоположение курсора

u

?

Восстановить местоположение курсора

`

HPA

Переместить курсор в указанный столбец текущей строки

Установка параметров графики ECMA-48

Последовательность ECMA-48 SGR управляющих символов ESC [ parameters m устанавливает атрибуты экрана. В одной последовательности может быть задано несколько атрибутов. Пустой параметр (между точкой с запятой или начальной строкой или символом завершения) считается нулём.

параметр

результат

0

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

1

установить жирный

2

установить более яркий (имитируется цветом на цветном дисплее)

4

установить подчеркивание (имитируется цветом на цветном дисплее) (цвета, используемые для имитации затемнения или подчеркивания, устанавливаются при помощи ESC ] …)

5

включить мерцание

7

включить инвертирование видео

10

сбросить выбранную перекодировку, флаг управления экраном и переключить метафлаг (в ECMA-48 указан как «первичный шрифт»).

11

выбрать null-перекодировку, установить флаг управления экраном, сбросить переключатель метафлага (в ECMA-48 указан как «первый альтернативный шрифт»).

12

выбрать null-перекодировку, установить флаг управления экраном, установить переключатель метафлага (в ECMA-48 указан как «второй альтернативный шрифт»). Переключение метафлага вызывает переключение старшего бита в байте до его перекодировки согласно таблице трансляции.

21

включить нормальную интенсивность (в ECMA-48 указан как «двойное подчёркивание»)

22

включить нормальную интенсивность

24

выключить подчеркивание

25

выключить мерцание

27

выключить инвертированное видео

30

установить чёрный цвет символов

31

установить красный цвет символов

32

установить зелёный цвет символов

33

установить коричневый цвет символов

34

установить синий цвет символов

35

установить сиреневый цвет символов

36

установить голубой цвет символов

37

установить белый цвет символов

38

включить подчеркивание, установить цвет символов по умолчанию

39

выключить подчеркивание, установить цвет символов по умолчанию

40

установить чёрный цвет фона

41

установить красный цвет фона

42

установить зелёный цвет фона

43

установить коричневый цвет фона

44

установить синий цвет фона

45

установить сиреневый цвет фона

46

установить голубой цвет фона

47

установить белый цвет фона

49

установить цвет фона по умолчанию

Переключатели режимов ECMA-48

ESC [ 3 h

DECCRM (по умолчанию выключен): Показывать управляющие символы.

ESC [ 4 h

DECIM (по умолчанию выключен): Включить режим вставки.

ESC [ 20 h

LF/NL (по умолчанию выключен): Автоматически выводить код CR после LF, VT или FF.

Команды вывода состояния ECMA-48

ESC [ 5 n

Сообщение о состоянии устройства (DSR): Ответом является ESC [ 0 n (терминал в порядке).

ESC [ 6 n

Сообщение о позиции курсора (CPR): Ответом является ESC [ y ; x R, где x,y являются координатами курсора.

Последовательности спец-режима DEC (DECSET/DECRST)

Не описаны в ECMA-48. Далее будут перечислены последовательности установки режима; в последовательности для сброса режима последний знак 'h' заменяется на 'l'.

ESC [ ? 1 h

DECCKM (по умолчанию выключено): Если включено, то клавиши курсора посылают префикс ESC O, а не с ESC [.

ESC [ ? 3 h

DECCOLM (по умолчанию = 80 столбцов): режим переключения количества столбцов 80/132. В исходном коде драйвера указано, что одной этой команды недостаточно; некоторые пользовательские утилиты, использующие нестандартные режимы, такие как resizecons(8), должны менять регистры настройки видеокарты консоли.

ESC [ ? 5 h

DECSCNM (по умолчанию выключено): Включить инвертированный видеорежим.

ESC [ ? 6 h

DECOM (по умолчанию выключено): Если включено, то координаты курсора рассматриваются относительно верхнего левого угла области прокрутки.

ESC [ ? 7 h

DECAWM (по умолчанию включено): Включить режим автопереноса. В этом режиме графический символ, вводящийся после 80-го столбца (или 132-го, если DECCOLM включён), переносится в начало следующей строки.

ESC [ ? 8 h

DECARM (по умолчанию включено): Включить режим автоповтора символов при вводе с клавиатуры.

ESC [ ? 9 h

Отчёт X10 о состоянии мыши (по умолчанию выключено): Установить режим отчёта о состоянии мыши, равным 1 (или сбросить в 0), см. ниже.

ESC [ ? 25 h

DECTECM (по умолчанию включено): Сделать курсор видимым.

ESC [ ? 1000 h

Отчёт X11 о состоянии мыши (по умолчанию выключено): Установить режим отчёта о состоянии мыши, равным 2 (или сбросить в 0), см. ниже.

Специфические CSI-последовательности консоли Linux

Следующие последовательности не являются ни ECMA-48, ни VT102. Они есть только в драйвере консоли Linux. Цвета в параметрах SGR: 0 = чёрный, 1 = красный, 2 = зелёный, 3 = коричневый, 4 = синий, 5 = сиреневый, 6 = голубой, 7 = белый, 8–15 = яркие версии 0–7.

ESC [ 1 ; n ]

Назначить цвет n цветом подчеркивания.

ESC [ 2 ; n ]

Назначить цвет n цветом затемнения.

ESC [ 8 ]

Сделать текущую пару цветов атрибутами по умолчанию

ESC [ 9 ; n ]

Показывать заставку через n минут

ESC [ 10 ; n ]

Задать частоту звукового сигнала (в герцах)

ESC [ 11 ; n ]

Задать длительность звукового сигнала (в миллисекундах)

ESC [ 12 ; n ]

Переместить указанную консоль перед остальными

ESC [ 13 ]

Убрать заставку (blank screen)

ESC [ 14 ; n ]

Задать интервал отключения питания VESA (в минутах)

ESC [ 15 ]

Переместить предыдущую консоль перед остальными (начиная с Linux 2.6.0)

ESC [ 16 ; n ]

Задать интервал мигания курсора (в миллисекундах) (начиная с Linux 4.2).

### Наборы символов
Ядро располагает информацией о 4-х типах трансляции байтов в символы консоли экрана. Эти четыре таблицы: a) Latin1 -> PC, b) графика VT100 -> PC, c) PC -> PC, d) определяется пользователем.

В системе существует два набора символов, называемых G0 и G1, и один из них является текущим набором символов системы (изначально это G0). Ввод ^N заставляет набор G1 стать текущим, ^O делает текущим набор G0.

Данные переменные G0 и G1 указывают на таблицу трансляции и могут меняться пользователем. Изначально они указывают на таблицы a) и b) соответственно. Последовательности ESC ( B, ESC ( 0, ESC ( U и ESC ( K заставляют G0 ссылаться на таблиц трансляции a), b), c) и d), соответственно. Последовательности ESC ) B, ESC ) 0, ESC ) U, и ESC ) K заставляют G1 ссылаться на таблицу трансляции a), b), c) и d), соответственно.

Последовательность ESC c приводит к сбросу терминала, то есть то, что вы хотели бы сделать при наличии «мусора» на экране. Рекомендация, указанная после «echo ^V^O», только сделает G0 текущим набором, но нет никакой гарантии, что G0 указывает на таблицу a). В некоторых дистрибутивах есть программа reset(1), которая всего лишь выполняет команду «echo ^[c». Если элемент terminfo является правильным для консоли (и содержит элемент rs1=\Ec), то «tput reset» также сработает.

Определенная пользователем таблица перекодировки может быть установлена с помощью mapscrn(8). Результатом перекодировки будет то, что при указании символа c в видеопамять будет отправлен символ s = перекодировка[c] . Побитовое изображение, соответствующее s, ищется в ПЗУ символов и может меняться при помощи setfont(8).

### Отслеживание мыши
Для отслеживания работы мыши в системе предполагается выдача xterm(1)-совместимых сигналов о состоянии мыши. Так как драйвер консоли не распознает такого устройства, как мышь (или похожего типа), то эти сигналы отправляются во входной поток консоли, только когда драйвер виртуального терминала получает сигнал ioctl об обновлении состояния мыши. Эти сигналы ioctl должны генерироваться пользовательскими приложениями, поддерживающими работу с мышью такими, как служба gpm(8).

Параметром для всех созданных xterm(1) экранирующих последовательностей (сигналов от мыши) будет один символ, код которого равен значение+040. Например, '!' соответствует единице. Отчёт системы координат экрана начинается с 1.

В режиме совместимости с X10 при нажатии на кнопки посылаются экранирующие последовательности, в которых кодируется и расположение мыши, и информация о нажатой кнопке. Режим включается при выдаче ESC [ ? 9 h и выключается при выдаче ESC [ ? 9 l. При нажатии на кнопку xterm(1) посылает ESC [ M bxy (6 символов), где b — это кнопка 1, а x и y равны координатам x и y при нажатии на кнопку. Это такие же коды, какие генерирует и выдаёт ядро.

В обычном режиме отслеживания мыши (который не был реализован в Linux 2.0.24) экранирующие последовательности посылаются и при нажатии и при отпускании кнопки мыши. Также посылается информация о модификаторе. Режим включается при выдаче ESC [ ? 1000 h и выключается при выдаче ESC [ 1000 l. При нажатии или отпускании кнопки xterm(1) выдает ESC [ M bxy. Два младших бита b содержат информацию о кнопках: 0=MB1 нажата, 1=MB2 нажата, 2=MB3 нажата, 3=отпущена. Старшие биты содержат информацию о том, какие модификаторы были нажаты, когда была нажата кнопка. Эта информация складывается при нажатии: 4=Shift, 8=Meta, 16=Control. Ещё раз: x и y являются координатами x и y мыши при обработке события. Координаты верхнего левого угла рассматриваются как (1,1).

### Сравнение с другими терминалами
Множество других типов терминалов описаны, подобно консоли Linux, как VT100-совместимые. Далее мы обсудим различия между консолью Linux и двумя другими важнейшими типами — DEC VT102 и xterm(1).

Обработка управляющих символов

Тип VT102 также распознает следующие управляющие символы:

NUL (0x00) игнорируется;

ENQ (0x05) запускает обратное ответное сообщение;

DC1 (0x11, ^Q, XON) возобновляет передачу;

DC3 (0x13, ^S, XOFF) заставляет VT100 игнорировать (и останавливать передачу) всех кодов за исключением XOFF и XON.

VT100-подобную обработку DC1/DC3 можно включить в драйвере терминала.

Программа xterm(1) (в режиме VT100) распознает управляющие символы BEL, BS, HT, LF, VT, FF, CR, SO, SI, ESC.

Экранирующие последовательности

Последовательности консоли VT100, не реализованные в консоли Linux:

ESC N

SS2

Сдвиг на 2 (выбрать набор символов G2 только для следующего

символа)

ESC O

SS3

Сдвиг на 3 (выбрать набор символов G3 только для следующего

символа)

ESC P

DCS

Строка управления устройством (заканчивается ESC \)

ESC X

SOS

Начало строки

ESC ^

PM

Частное сообщение (заканчивается ESC \)

ESC \

ST

Символ завершения строки

ESC * ...

Определить набор символов G2

ESC + ...

Определить набор символов G3

Программа xterm(1) (в режиме VT100) распознает ESC c, ESC # 8, ESC >, ESC =, ESC D, ESC E, ESC H, ESC M, ESC N, ESC O, ESC P ... ESC \, ESC Z (отвечает ESC [ ? 1 ; 2 c, "Я VT100 с улучшенными видеопараметрами") и ESC ^ ... ESC \ с теми же значениями, какие указаны выше. Принимаются ESC (, ESC ), ESC *, ESC + за которыми 0, A, B для специального символа DEC и режима рисования линий, UK и US-ASCII, соответственно.

Пользователь может настроить xterm(1) так, чтобы он отвечал на специальные управляющие последовательности VT220, и в этом случае он будет идентифицировать себя как VT52, VT100 и далее, в зависимости от способа настройки и инициализации.

Для настройки определённых ресурсов он принимает ESC ] (OSC). Помимо символа завершения строки (ST) из ECMA-48, xterm(1) для завершения OSC-строки также принимает BEL. Есть несколько управляющих последовательностей OSC, распознаваемых xterm(1):

ESC ] 0 ; txt ST

Установить имя значка и заголовок окна равным txt

ESC ] 1 ; txt ST

Установить имя значка равным txt

ESC ] 2 ; txt ST

Установить заголовок окна равным txt

ESC ] 4 ; num; txt ST

Установить цвет ANSI num равным txt

ESC ] 10 ; txt ST

Установить цвет динамического текста равным txt

ESC ] 4 6 ; name ST

Изменить файл журнала на name (обычно отключено

в параметрах компиляции)

ESC ] 5 0 ; fn ST

Установить шрифт равным fn.

Распознаются следующие параметры с несколько измененным значением (больше сохраняется состояние, поведение ближе к VT100/VT220):

ESC 7 DECSC

Сохранить курсор

ESC 8 DECRC

Восстановить курсор

Также распознаются

ESC F

Курсор в нижний левый угол экрана (если разрешено

ресурсом hpLowerleftBugCompat в xterm(1))

ESC l

Блокировать память (терминалы HP)

Блокировать память выше курсора

ESC m

Разблокировать память (терминалы HP)

ESC n

LS2

Вызов набора символов G2

ESC o

LS3

Вызов набора символов G3

ESC |

LS3R

Вызов набора символов G3 в качестве GR

ESC }

LS2R

Вызов набора символов G2 в качестве GR

ESC ~

LS1R

Вызов набора символов G1 в качестве GR

Также распознается ESC % и предоставляется более полная реализация UTF-8 чем в консоли Linux.

Последовательности CSI

Старые версии xterm(1), например из X11R5, воспринимают мерцание SGR как жирность SGR. В более новых версиях, в которых реализованы цвета ANSI, например в XFree86 3.1.2A 1995 года, атрибут мерцания отображается цветом. В современных версиях xterm мерцание SGR реализовано в виде мерцающего текста, который можно также сделать цветным в качестве альтернативы отображения SGR. Исходные версии X11R6 не распознают настройки цвета SGR вплоть до версии X11R6.8, в которую был включён XFree86 xterm. Все последовательности CSI ECMA-48 CSI, понимаемые Linux, также понимает xterm, однако в xterm(1) реализовано несколько управляющих последовательностей ECMA-48 и DEC, которые не понимаются Linux.

Программа xterm(1) распознаёт все последовательности спец-режимов DEC, описанных выше, но ни одной последовательности спец-режимов Linux. О собственных спец-режимах xterm(1) можно прочитать в документе Управляющие последовательности Xterm, написанном Edward Moy, Stephen Gildea и Thomas E. Dickey и доступном в дистрибутиве X. Этот документ хотя и сокращённый, но всё равно намного больше данной справочной страницы. Хронологический обзор в

http://invisible-island.net/xterm/xterm.log.html

описывает изменения в xterm.

Программа vttest

http://invisible-island.net/vttest/

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

## ЗАМЕЧАНИЯ
Последовательность ESC 8 (DECRC) не может восстановить набор символов, изменённый с помощью ESC %.

## ДЕФЕКТЫ
В версии 2.0.23 набор CSI является неправильным и недейственным, NUL не игнорируется внутри экранирующих последовательностей.

Некоторые старые версии ядер (после 2.0) анализируют 8-битные управляющие последовательности. В них ("управляющие коды C1") используются коды от 128 до 159 для замены ESC [, ESC ] и подобных начальных двухбайтовых управляющих последовательностей. Они частично существуют в современных ядрах (или не распознаются или не работают из-за поддержки UTF-8), и реализованы не полностью, и должны расцениваться как ненадежные.

Последовательности "спец-режима" Linux не учитывают правила ECMA-48 для управляющих последовательностей спец-режима. В частности, они заканчиваются ] и не используют стандартный символ завершения. Последовательность OSC (установить палитру) — большая проблема, так как xterm(1) рассматривает её как управляющую последовательность, которой требуется окончание строки (ST). В отличие от последовательностей setterm(1), которые будут проигнорированы (так как они не являются правильными управляющими последовательностями), последовательность палитры приведёт к подвисанию xterm(1) (хотя нажав клавишу return это исправится). Чтобы приспособить приложения, в которых жёстко заданы управляющие последовательности Linux, установите ресурс xterm(1) brokenLinuxOSC равным true.

В старой версии данного документа предполагалось, что Linux распознаёт управляющую последовательность ECMA-48 для невидимости текста. Она игнорируется.

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


cpuid

title: cpuid(4)

text:
# cpuid(4)

## ИМЯ
cpuid - устройство доступа к CPUID в процессорах x86

## ОПИСАНИЕ
CPUID предоставляет интерфейс для получения информации о процессоре x86.

Для перехода на нужный уровень CPUID достаточно выполнить на устройстве lseek(2) или pread(2); чтение происходит порциями по 16 байт. Для получения большего количества данных нужно повторить операцию чтения на последующих уровнях.

Младшие 32 бита позиции файла используются как входящее значение для регистра %eax, а старшие 32 бита как входящее значение для %ecx, последнее предназначено для "подсчёта" уровней eax, например eax=4.

Этот драйвер использует устройства /dev/cpu/CPUNUM/cpuid, где CPUNUM указывает на младший номер, а в многопроцессорных машинах CPUNUM указывает на номер процессора, которые перечислены в /proc/cpuinfo.

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

## ЗАМЕЧАНИЯ
Инструкция CPUID может непосредственно выполняться программой с помощью встроенных в языки ассемблерных вставок. Однако это устройство предоставляет удобный доступ ко всем процессорам без изменения в программе.

Большинство информации cpuid можно получить в готовом виде из файла /proc/cpuinfo или подкаталогов /sys/devices/system/cpu. Непосредственное использование CPUID через это устройство нужно использовать только в специальных случаях.

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

```
$ modprobe cpuid
```

Функции CPUID с дополнительными входными регистра не поддерживаются.

Очень старые процессоры x86 не поддерживают CPUID.

## СМОТРИТЕ ТАКЖЕ
cpuid(1)

Intel Corporation, Intel 64 and IA-32 Architectures Software Developer's Manual Volume 2A: Instruction Set Reference, A-M, 3-180 CPUID reference.

Intel Corporation, Intel Processor Identification and the CPUID Instruction, Application note 485.


title: dsp56k(4)

summary: устройство интерфейса DSP56001

text:
# dsp56k(4)

## ИМЯ
dsp56k - устройство интерфейса DSP56001

## ОБЗОР

```
#include <asm/dsp56k.h>
```

```
ssize_t read(int fd, void *data, size_t length);
ssize_t write(int fd, void *data, size_t length);
```

```
int ioctl(int fd, DSP56K_UPLOAD, struct dsp56k_upload *program);
int ioctl(int fd, DSP56K_SET_TX_WSIZE, int wsize);
int ioctl(int fd, DSP56K_SET_RX_WSIZE, int wsize);
int ioctl(int fd, DSP56K_HOST_FLAGS, struct dsp56k_host_flags *flags);
int ioctl(int fd, DSP56K_HOST_CMD, int cmd);
```

## НАСТРОЙКА
Устройство dsp56k является символьным устройством с старшим номером 55 и младшим номером 0.

## ОПИСАНИЕ
Motorola DSP56001 — это полностью программируемый 24-битный цифровой сигнальный процессор, используемый в компьютерах Atari Falcon030 и совместимых с ними. Специальный файл dsp56k используется для управления DSP56001 и для посылки и получения данных через выбранный на узле (host) двунаправленный порт.

Для отправки потока данных сигнальному процессору, используйте write(2), а для получения обработанных данных — read(2). Данные могут быть посылаться и получаться узлом по 8, 16, 24 или 32 бита, а сигнальный процессор способен обрабатывать только по 24 бита.

Для управления устройством dsp56k используются следующие вызовы ioctl(2):

DSP56K_UPLOAD

Обнуляет DSP56001 и загружает в него программу. Третьим аргументом ioctl(2) должен быть указатель на struct dsp56k_binary, в которое поле bin указывает на двоичную программу DSP56001, а в len задаётся длина программы (значение должно быть кратно 24-битным словам).

DSP56K_SET_TX_WSIZE

Устанавливает размер передаваемых слов. Допустимое значение находится в пределах от 1 до 4, и является числом байт, посылаемых за один раз в DSP56001. Эти частички информации будут заполнены нулевыми байтами или преобразованы в формат 24-битных данных DSP56001.

DSP56K_SET_RX_WSIZE

Устанавливает размер принимаемых слов. Допустимое значение находится в диапазоне от 1 до 4, и является числом байт, принимаемых за один раз от процессора DSP56001. Эти частички информации будут урезаны или дополнены байтом null ('\0'), чтобы соответствовать 24-битному формату DSP56001.

DSP56K_HOST_FLAGS

Считывает и записывает флаги узла. Флаги узла — это четыре бита общего назначения, они могут быть считаны как узлом, так и процессором DSP56001. Нулевой и первый биты могут записываться узлом, а второй и третий пишутся устройством DSP56001.

Для получения доступа к флагам узла третий аргумент ioctl(2) должен быть указателем на struct dsp56k_host_flags. Если нулевой и первый поля dir установлены в единичное значение, то соответствующий бит в поле out будет записан в флаг узла. Состояние всех флагов узла будет возвращено в младших четырёх битах поля status.

DSP56K_HOST_CMD

Посылает команды узла. Допустимые величины находятся в диапазоне от 0 до 31, это определяемые пользователем команды, обрабатываемые программой, выполняющейся на DSP56001.

## ФАЙЛЫ
/dev/dsp56k

## СМОТРИТЕ ТАКЖЕ
linux/include/asm-m68k/dsp56k.h, linux/drivers/char/dsp56k.c, http://dsp56k.nocrew.org/, DSP56000/DSP56001 Digital Signal Processor User's Manual


fd

title: fd(4)

summary: устройство для работы с дисководом

text:
# fd(4)

## ИМЯ
fd - устройство для работы с дисководом

## НАСТРОЙКА
Дисководы гибких дисков — блочные устройства со старшим номером 2. Обычно их владельцем является root.floppy (т.е. пользователь root, группа floppy), а права доступа к ним — 0660 (доступно членам группы) или 0666 (доступно всем). Младший номер определяется типом устройства, номером устройства, и номером контроллера. Для каждого типа устройства, то есть комбинации объёма и количества дорожек, существует базовый младший номер. К этому базовому номеру прибавьте номер устройства в пределах его контроллера и ещё 128, если дисковод подключен к вторичному контроллеру. В нижеследующих таблицах n означает номер дисковода.

Предупреждение: Если вы используете формат дискет с большим числом дорожек, чем поддерживает ваш дисковод, вы можете вызвать механическое повреждение. Однократная попытка поработать с числом дорожек больше обычных 40/80, не должна его повредить, но нет гарантии, что этого не произойдет. Если вы не уверены, не создавайте устройства для таких форматов, чтобы предотвратить их использование.

Файлы устройств, не зависящие от дисковода, которые автоматически определяют формат носителя и ёмкость диска:

Имя

Основной

младший №

fdn

0

Файлы устройств с носителями 5.25 дюймов с двойной плотностью:

Имя

Ёмкость

Цил.

Сект.

Головок

Основной

КиБ

младший №

fdnd360

360

40

9

2

4

Файлы устройств с носителями 5.25 дюйма и повышенной плотностью:

Имя

Ёмкость

Цил.

Сект.

Головок

Основной

КиБ

младший №

fdnh360

360

40

9

2

20

fdnh410

410

41

10

2

48

fdnh420

420

42

10

2

64

fdnh720

720

80

9

2

24

fdnh880

880

80

11

2

80

fdnh1200

1200

80

15

2

8

fdnh1440

1440

80

18

2

40

fdnh1476

1476

82

18

2

56

fdnh1494

1494

83

18

2

72

fdnh1600

1600

80

20

2

92

Файлы устройств с носителями 3.5 дюйма и двойной плотностью:

Имя

Ёмкость

Цил.

Сект.

Головок

Основной

КиБ

младший №

fdnu360

360

80

9

1

12

fdnu720

720

80

9

2

16

fdnu800

800

80

10

2

120

fdnu1040

1040

80

13

2

84

fdnu1120

1120

80

14

2

88

Файлы устройств с носителями 3.5 дюйма и повышенной плотностью:

Имя

Ёмкость

Цил.

Сект.

Головок

Основной

КиБ

младший №

fdnu360

360

40

9

2

12

fdnu720

720

80

9

2

16

fdnu820

820

82

10

2

52

fdnu830

830

83

10

2

68

fdnu1440

1440

80

18

2

28

fdnu1600

1600

80

20

2

124

fdnu1680

1680

80

21

2

44

fdnu1722

1722

82

21

2

60

fdnu1743

1743

83

21

2

76

fdnu1760

1760

80

22

2

96

fdnu1840

1840

80

23

2

116

fdnu1920

1920

80

24

2

100

Файлы устройств с носителями 3.5 дюйма и сверх плотностью:

Имя

Ёмкость

Цил.

Сект.

Головок

Основной

КиБ

младший №

fdnu2880

2880

80

36

2

32

fdnCompaQ

2880

80

36

2

36

fdnu3200

3200

80

40

2

104

fdnu3520

3520

80

44

2

108

fdnu3840

3840

80

48

2

112

## ОПИСАНИЕ
Специальные файлы fd обеспечивают доступ к дисководам в режиме без обработки (raw mode). Устройства fd поддерживают следующие вызовы ioctl(2):

FDCLRPRM

Очищает информацию о носителе в дисководе (геометрию диска в дисководе).

FDSETPRM

Устанавливает информацию о носителе в дисководе. Информация о носителе потеряется, когда носитель будет сменён.

FDDEFPRM

Устанавливает информацию о носителе в дисководе (геометрию диска в дисководе). Информация о носителе не будет потеряна, когда носитель будет сменён. При этом автоопределение носителя будет выключено. Чтобы снова его включить, выполните FDCLRPRM.

FDGETDRVTYP

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

FDFLUSH

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

FDSETMAXERRS

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

FDSETMAXERRS

Возвращает текущие пороговые значения для ошибок.

FDGETDRVTYP

Возвращает внутреннее имя дисковода.

FDWERRORCLR

Очищает статистику ошибок записи.

FDWERRORGET

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

FDTWADDLE

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

FDSETDRVPRM

Устанавливает различные параметры дисковода.

FDGETDRVPRM

Возвращает различные параметры.

FDGETDRVSTAT

Возвращает кэшированное состояние дисковода (диск сменён, защищён от записи и т. д.)

FDPOLLDRVSTAT

Обращается к дисководу и возвращает его состояние.

FDGETFDCSTAT

Возвращает состояние контроллера дисководов.

FDRESET

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

FDRAWCMD

Посылает команду в необработанном виде (raw command) контроллеру дисководов.

За более точной информацией обратитесь также к файлам <linux/fd.h> и <linux/fdreg.h>, а также к справочной странице floppycontrol(1).

## ФАЙЛЫ
/dev/fd*

## ЗАМЕЧАНИЯ
Разные форматы позволяют читать и записывать многие типы дисков. Однако, если дискета отформатирована со слишком маленьким межсекторным промежутком, производительность может снизиться вплоть до того, что для доступа к дорожке может понадобиться несколько секунд. Во избежание этого, используйте перемежающиеся (interleaved) форматы.

Невозможно прочитать дискеты, отформатированные с использованием GCR (групповая запись кодов), которые используются компьютерами Apple II и Macintosh (диски 800k).

Чтение аппаратно размеченных на секторы дискет (с отверстием на каждый сектор и слегка повернутым индексным отверстием) не поддерживается. Такими были старые 8-дюймовые дискеты.

## СМОТРИТЕ ТАКЖЕ
chown(1), floppycontrol(1), getfdprm(1), mknod(1), superformat(1), mount(8), setfdprm(8)


full

title: full(4)

summary: всегда полное устройство

text:
# full(4)

## ИМЯ
full - всегда полное устройство

## НАСТРОЙКА
Если в системе нет файла /dev/full, то его можно создать при помощи следующих команд:

```
mknod -m 666 /dev/full c 1 7
chown root:root /dev/full
```

## ОПИСАНИЕ
Файл /dev/full имеет основной номер устройства, равный 1, и второстепенный, равный 7.

При записи в устройство /dev/full возвращается ошибка ENOSPC. Это можно использовать для проверки обработки ошибки переполнения диска в программе.

При попытке чтения файла /dev/full будут возвращаться символы \0.

Перемещение по /dev/full всегда выполняется успешно.

## ФАЙЛЫ
/dev/full

## СМОТРИТЕ ТАКЖЕ
mknod(1), null(4), zero(4)


fuse

title: fuse(4)

text:
# fuse(4)

## ИМЯ
fuse - устройство файловой системы в пользовательском пространстве (FUSE)

## ОБЗОР

```
#include <linux/fuse.h>
```

## ОПИСАНИЕ
Это устройство является основным интерфейсом между драйвером файловой системы FUSE и процессом в пользовательском пространстве, который будет предоставлять файловую систему (далее здесь называется службой файловой системы (filesystem daemon)). Данная справочная страница предназначена тому, кто заинтересован в понимании интерфейса самого ядра. Тем, кто реализует файловую систему FUSE, важнее описание библиотеки пользовательского пространства такой как libfuse, которая скрывает низкоуровневый интерфейс.

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

### Основной протокол
Каждое сообщение, читаемое службой, начинается с заголовка следующей структуры:

```
struct fuse_in_header {

    uint32_t len;       /* общая длина данных,

                           включая этот заголовок */

    uint32_t opcode;    /* тип операции (смотрите ниже) */

    uint64_t unique;    /* уникальный идентификатор этого запроса */

    uint64_t nodeid;    /* ID объекта файловой системы, с

                           которым выполняется действие */

    uint32_t uid;       /* UID запрашивающего процесса */

    uint32_t gid;       /* GID запрашивающего процесса */

    uint32_t pid;       /* PID запрашивающего процесса */

    uint32_t padding;
};
```

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

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

```
struct fuse_out_header {

    uint32_t len;       /* общая длина данных, записываемых

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

    int32_t  error;     /* возникшая ошибка (0, если нет) */

    uint64_t unique;    /* значение из

                           соответствующего запроса */
};
```

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

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

FUSE_INIT

```
struct fuse_init_in {

    uint32_t major;

    uint32_t minor;

    uint32_t max_readahead; /* начиная с протокола v7.6 */

    uint32_t flags;         /* начиная с протокола v7.6 */
};

```

Это первый запрос, посылаемый ядром службе. Он используется для согласования версии протокола и других параметров файловой системы. Заметим, что версия протокола может влиять на любую структуру протокола (включая эту). Служба должна запоминать согласованную версию и флаги для каждого сеанса. На момент написания этой справочной страницы наибольшей версией поддерживаемого ядром протокола была 7.26.

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

Ответ на этот запрос имеет следующий формат:

```
struct fuse_init_out {

    uint32_t major;

    uint32_t minor;

    uint32_t max_readahead;   /* Начиная с v7.6 */

    uint32_t flags;           /* Начиная с v7.6; некоторые биты флагов были введены позднее */

    uint16_t max_background;  /* Начиная с v7.13 */

    uint16_t congestion_threshold;  /* Начиная с v7.13 */

    uint32_t max_write;       /* Начиная с v7.5 */

    uint32_t time_gran;       /* Начиная с v7.6 */

    uint32_t unused[9];
};

```

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

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

FUSE_GETATTR

```
struct fuse_getattr_in {

    uint32_t getattr_flags;

    uint32_t dummy;

    uint64_t fh;      /* задаётся, только если

                         (getattr_flags & FUSE_GETATTR_FH)
};

```

Операция запроса вычисления атрибутов, возвращаемых stat(2) и подобными операциями для указанного объекта файловой системы. Объект, для которого вычисляются атрибуты, задаётся в виде header->nodeid или, если указан флаг FUSE_GETATTR_FH, в виде файлового описателя (handle) fh. Для последнего случая операция аналогична fstat(2).

С целью оптимизации производительности, эти атрибуты могут кэшироваться в ядре на указанный период времени. Пока срок хранения кэша не истёк, атрибуты будут браться из кэша и дополнительные запросы FUSE_GETATTR выполняться не будут.

Вычисленные атрибуты и срок хранения в кэше возвращаются в следующей структуре:

```
struct fuse_attr_out {

    /* срок хранения атрибута в кэше (секунды + наносекунды) */

    uint64_t attr_valid;

    uint32_t attr_valid_nsec;

    uint32_t dummy;

    struct fuse_attr {

        uint64_t ino;

        uint64_t size;

        uint64_t blocks;

        uint64_t atime;

        uint64_t mtime;

        uint64_t ctime;

        uint32_t atimensec;

        uint32_t mtimensec;

        uint32_t ctimensec;

        uint32_t mode;

        uint32_t nlink;

        uint32_t uid;

        uint32_t gid;

        uint32_t rdev;

        uint32_t blksize;

        uint32_t padding;

    } attr;
};

```

FUSE_ACCESS

```
struct fuse_access_in {

    uint32_t mask;

    uint32_t padding;
};

```

Если не используется параметр монтирования default_permissions, то этот запрос можно использовать для проверки прав доступа. Данных в ответе не ожидается, но могут возвращаться ошибки, как обычно в поле error заголовка ответа (в частности, при ошибках отказа в доступе может возвращаться -EACCES).

FUSE_OPEN и FUSE_OPENDIR

```
struct fuse_open_in {

    uint32_t flags;     /* флаги, передаваемые

                           в open(2) */

    uint32_t unused;
};

```

Этот запрос открывает ноду, указанную в header->nodeid. Точна семантика будет зависеть от реализации в файловой системе. Однако, по крайней мере, файловая система должна проверить что запрашиваемые flags корректны для указанного ресурса и затем послать ответ в следующем формате:

```
struct fuse_open_out {

    uint64_t fh;

    uint32_t open_flags;

    uint32_t padding;
};

```

Поле fh представляет собой закрытый (opaque) идентификатор, который ядро будет использовать для ссылки на этот ресурс. Поле open_flags представляет собой битовую маску с набором флагов, которые определяют свойства этого описателя в ядре:

FOPEN_DIRECT_IO

Не использовать страничный кэш для этого открытого файла.

FOPEN_KEEP_CACHE

Не делать недействительными данные кэша при открытии.

FOPEN_NONSEEKABLE

Внутри файла не поддерживается смена положения.

FUSE_READ и FUSE_READDIR

```
struct fuse_read_in {

    uint64_t fh;

    uint64_t offset;

    uint32_t size;

    uint32_t read_flags;

    uint64_t lock_owner;

    uint32_t flags;

    uint32_t padding;
};

```

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

FUSE_INTERRUPT

```
struct fuse_interrupt_in {

    uint64_t unique;
};

```

По этому запросу отменяется ожидающая операция, указанная в unique. По запросу не формируется ответ. Однако, само получение сообщения не отменяет указанную операцию. Ядро всё равно будет ждать ответа на указанную операцию (например, ошибку EINTR или короткое чтение). Для указанной операции будет выдано не более одно запроса FUSE_INTERRUPT. После выдачи указанной операции ядро будет непрерывно ожидать завершения указанного запроса.

FUSE_LOOKUP

Непосредственно после заголовка указывается имя файла, которое будет искаться в каталоге, указанном в header->nodeid. Ожидается ответ в виде:

```
struct fuse_entry_out {

    uint64_t nodeid;            /* идентификатор inode */

    uint64_t generation;        /* поколение inode */

    uint64_t entry_valid;

    uint64_t attr_valid;

    uint32_t entry_valid_nsec;

    uint32_t attr_valid_nsec;

    struct fuse_attr attr;
};

```

Комбинация nodeid и generation должна быть уникальной на время существования файловой системы.

Параметры сроков хранения и attr такие же как в FUSE_GETATTR.

FUSE_FLUSH

```
struct fuse_flush_in {

    uint64_t fh;

    uint32_t unused;

    uint32_t padding;

    uint64_t lock_owner;
};

```

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

FUSE_RELEASE и FUSE_RELEASEDIR

```
struct fuse_release_in {

    uint64_t fh;

    uint32_t flags;

    uint32_t release_flags;

    uint64_t lock_owner;
};

```

Запросы, обратные FUSE_OPEN и FUSE_OPENDIR, соответственно. Служба теперь может освободить ресурсы, связанные с файловым описателем fh, так как ядру он больше не нужен. Данных в ответе не посылается, но ответ нужно отправить после обработки запроса.

FUSE_STATFS

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

```
struct fuse_kstatfs {

    uint64_t blocks;

    uint64_t bfree;

    uint64_t bavail;

    uint64_t files;

    uint64_t ffree;

    uint32_t bsize;

    uint32_t namelen;

    uint32_t frsize;

    uint32_t padding;

    uint32_t spare[6];
};
struct fuse_statfs_out {

    struct fuse_kstatfs st;
};

```

Информацию об этих полях смотрите в statfs(2).

## ОШИБКИ
E2BIG

Возвращается из операций read(2), когда запросы ядра слишком велики для предоставляемого буфера и запросом является FUSE_SETXATTR.

EINVAL

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

EIO

Возвращается из операции read(2), когда запросы ядра слишком велики для предоставляемого буфера.

Замечание: Есть несколько вариантов, в которых неправильное использование этих интерфейсов с предоставляемыми файловой системой файлами и каталогами может завершиться ошибкой EIO. Например:

- изменение mode & S_IFMT для иноды, о которой ранее было сообщено ядру; или

- выдача более коротких ответов ядру, чем оно ожидает.

ENODEV

Возвращается из операций read(2) и write(2), если файловая система FUSE была размонтирована.

EPERM

Возвращается из операций над файловым дескриптором /dev/fuse, если он не был смонтирован.

## СООТВЕТСТВИЕ СТАНДАРТАМ
Файловая система FUSE есть только в Linux.

## ЗАМЕЧАНИЯ
Следующие сообщения пока не документированы в этой справочной странице:

```
FUSE_BATCH_FORGET
FUSE_BMAP
FUSE_CREATE
FUSE_DESTROY
FUSE_FALLOCATE
FUSE_FORGET
FUSE_FSYNC
FUSE_FSYNCDIR
FUSE_GETLK
FUSE_GETXATTR
FUSE_IOCTL
FUSE_LINK
FUSE_LISTXATTR
FUSE_LSEEK
FUSE_MKDIR
FUSE_MKNOD
FUSE_NOTIFY_REPLY
FUSE_POLL
FUSE_READDIRPLUS
FUSE_READLINK
FUSE_REMOVEXATTR
FUSE_RENAME
FUSE_RENAME2
FUSE_RMDIR
FUSE_SETATTR
FUSE_SETLK
FUSE_SETLKW
FUSE_SYMLINK
FUSE_UNLINK
FUSE_WRITE
```

## СМОТРИТЕ ТАКЖЕ
fusermount(1), mount.fuse(8)


hd

title: hd(4)

summary: устройства для жёстких дисков MFM/IDE

text:
# hd(4)

## ИМЯ
hd - устройства для жёстких дисков MFM/IDE

## ОПИСАНИЕ
Устройства hd* — это блочные устройства для прямого доступа к жёстким дискам MFM/IDE. Для главного (master) диска на первичном контроллере IDE (старший номер 3) назначается имя hda; для зависимого (slave) диска — hdb. Для главного диска на вторичном контроллере (старший номер 22) — hdc, а для зависимого — hdd.

Названия блочных устройств IDE имеют вид hdX или hdXP, где X — буква, указывающая на физический диск, а P — номер, указывающий на раздел этого физического диска. Первая форма, hdX, используется для обращения ко всему диску. Номера разделов назначаются в порядке их обнаружения, и номера присваиваются только «не пустым», не расширенным разделам. Однако, номера с первого по четвертый присваиваются разделам, описанным в MBR («основным» (primary) разделам), независимо от того, используются ли они или являются ли расширенными (extended). Поэтому первым логическим разделом будет hdX5. Поддерживается как таблица разделов DOS, так и BSD-disklabel. На IDE-диске может быть не более 63-х разделов.

Например, /dev/hda ссылается на весь первый физический диск IDE, а /dev/hdb3 ссылается на третий, "основной", раздел DOS второго физического диска.

Файлы устройств, обычно, создаются следующим образом:

```
mknod -m 660 /dev/hda b 3 0
mknod -m 660 /dev/hda1 b 3 1
mknod -m 660 /dev/hda2 b 3 2
...
mknod -m 660 /dev/hda8 b 3 8
mknod -m 660 /dev/hdb b 3 64
mknod -m 660 /dev/hdb1 b 3 65
mknod -m 660 /dev/hdb2 b 3 66
...
mknod -m 660 /dev/hdb8 b 3 72
chown root:disk /dev/hd*
```

## ФАЙЛЫ
/dev/hd*

## СМОТРИТЕ ТАКЖЕ
chown(1), mknod(1), sd(4), mount(8)


hpsa

title: hpsa(4)

summary: драйвер SCSI для HP Smart Array

text:
# hpsa(4)

## ИМЯ
hpsa - драйвер SCSI для HP Smart Array

## ОБЗОР

```
modprobe hpsa [ hpsa_allow_any=1 ]
```

## ОПИСАНИЕ
hpsa — это драйвер SCSI для контроллеров RAID HP Smart Array.

### Параметры
hpsa_allow_any=1: Этот параметр разрешает драйверу попытаться управлять аппаратурой любого контроллера RAID HP Smart Array, даже если его модель неизвестна драйверу. Это позволяет новому оборудованию работать через старые драйверы. Обычно, данный параметр используется для того, чтобы позволить установить операционную систему с носителя, который был создан раньше контроллера RAID, а также он может использоваться для обслуживания драйвером hpsa старых контроллеров, которые, обычно, работают через драйвер cciss(4). Такие старые карты не тестировались и не поддерживаются hpsa; для них пока всё же лучше использовать cciss(4).

### Поддерживаемое оборудование
Драйвер hpsa поддерживает следующие карты Smart Array:

```
    Smart Array P700M

    Smart Array P212

    Smart Array P410

    Smart Array P410i

    Smart Array P411

    Smart Array P812

    Smart Array P712m

    Smart Array P711m

    StorageWorks P1210m
```

Начиная с Linux 4.14 также поддерживаются следующие платы Smart Array:

```
    Smart Array 5300

    Smart Array 5312

    Smart Array 532

    Smart Array 5i

    Smart Array 6400

    Smart Array 6400 EM

    Smart Array 641

    Smart Array 642

    Smart Array 6i

    Smart Array E200

    Smart Array E200i

    Smart Array E200i

    Smart Array E200i

    Smart Array E200i

    Smart Array E500

    Smart Array P400

    Smart Array P400i

    Smart Array P600

    Smart Array P700m

    Smart Array P800
```

### Особенности настройки
Для настройки контроллеров HP Smart Array используйте HP Array Configuration Utility (hpacuxe(8) или hpacucli(8)) или Offline ROM-based Configuration Utility (ORCA), которую можно запустить из ROM Smart Array при старте машины.

## ФАЙЛЫ

### Узлы устройства
Логические диски доступны через драйвер дисков SCSI (sd(4)), ленточные устройства — через драйвер лент SCSI (st(4)), а контроллеры RAID — через общий драйвер SCSI (sg(4)); имена узлов устройств называются /dev/sd*, /dev/st* и /dev/sg*, соответственно.

### Файлы в /sys, относящиеся к атрибутам узла HPSA
/sys/class/scsi_host/host*/rescan

Атрибут только для записи. Факт записи заставляет драйвер выполнить сканирование на предмет появления новых, изменившихся или удалённых устройств (например, подключаемых на ходу ленточных накопителей или только что настроенных или удалённых логических дисков и т. д.) и уведомить прослойку (midlayer) SCSI об обнаруженных изменениях. Обычно, пересканирование выполняется автоматически утилитой настройки HP Array (из графического интерфейса или командной строки); поэтому при изменении логических дисков, обычно, пользователь не должен использовать этот атрибут. Данный атрибут полезен при подключении на ходу устройств, таких как ленточные накопители или хранилищ с уже настроенными логическими дисками.

/sys/class/scsi_host/host*/firmware_revision

В данном атрибуте хранится версия микропрограммы Smart Array.

Пример:

```
# cd /sys/class/scsi_host/host4
# cat firmware_revision
7.14

```

### Файлы в /sys, относящиеся к атрибутам диска HPSA
/sys/class/scsi_disk/c:b:t:l/device/unique_id

В данном атрибуте хранится 32 шестнадцатеричных цифры уникального идентификатора для каждого логического диска.

Пример:

```
# cd /sys/class/scsi_disk/4:0:0:0/device
# cat unique_id
600508B1001044395355323037570F77

```

/sys/class/scsi_disk/c:b:t:l/device/raid_level

В данном атрибуте хранится уровень RAID каждого логического диска.

Пример:

```
# cd /sys/class/scsi_disk/4:0:0:0/device
# cat raid_level
RAID 0

```

/sys/class/scsi_disk/c:b:t:l/device/lunid

В данном атрибуте хранится 16 шестнадцатеричных цифры (8 байт) идентификатора LUN, который может адресовать логический или физический диск. Форматом c:b:t:l описывается контроллер, шина, целевое устройство (target) и lun устройства.

Пример:

```
# cd /sys/class/scsi_disk/4:0:0:0/device
# cat lunid
0x0000004000000000

```

### Поддерживаемые операции ioctl()
Для совместимости с приложениями, написанными для драйвера cciss(4), в драйвере hpsa поддерживаются многие ioctl из драйвера cciss(4) (но не все). Структуры данных, используемые в ioctl, описаны в файле исходного кода ядра Linux include/linux/cciss_ioctl.h.

CCISS_DEREGDISK, CCISS_REGNEWDISK, CCISS_REGNEWD

Это три ioctl выполняют одинаковую работу — заставляют драйвер искать новые устройства. Это тоже самое, как если выполнить запись в hpsa-атрибут узла «rescan».

CCISS_GETPCIINFO

Возвращает домен PCI, шину, устройство, функцию и «board ID» (ID подсистемы PCI).

CCISS_GETDRIVVER

Возвращает версию драйвера в виде трёх байт в формате:

```
(major_version << 16) | (minor_version << 8) |

    (subminor_version)

```

CCISS_PASSTHRU, CCISS_BIG_PASSTHRU

Разрешает передавать команды «BMIC» и «CISS» в Smart Array. Они часто используются в HP Array Configuration Utility, SNMP-агентах хранилищ и т. д. Примеры смотрите в http://cciss.sf.net в разделе о cciss_vol_status.

## СМОТРИТЕ ТАКЖЕ
cciss(4), sd(4), st(4), cciss_vol_status(8), hpacucli(8), hpacuxe(8),

http://cciss.sf.net, and Documentation/scsi/hpsa.txt и Documentation/ABI/testing/sysfs-bus-pci-devices-cciss в дереве исходного кода ядра Linux


initrd

title: initrd(4)

summary: RAM\-диск, инициализируемый загрузчиком

text:
# initrd(4)

## ИМЯ
initrd - RAM-диск, инициализируемый загрузчиком

## НАСТРОЙКА
Устройство /dev/initrd — это блочное устройство, доступное только для чтения, имеющее старший номер 1 и младший номер 250. Обычно, /dev/initrd принадлежит root:disk с правами 0400 (читать может только root). Если /dev/initrd ещё не создано, то это можно сделать с помощью команд:

```
mknod -m 400 /dev/initrd b 1 250
chown root:disk /dev/initrd
```

Для использования /dev/initrd с поддержкой «диска в RAM» и «начального диска в RAM» ядро Linux должно быть собрано с параметрами CONFIG_BLK_DEV_RAM=y и CONFIG_BLK_DEV_INITRD=y. При использовании /dev/initrd драйвер диска в RAM не может загружаться как модуль.

## ОПИСАНИЕ
Специальный файл /dev/initrd — блочное устройство, доступное только для чтения. Данное устройство представляет собой диск, расположенный в оперативной памяти, который инициализируется (т.е. загружается) системным загрузчиком до запуска ядра. Затем ядро может использовать содержимое блочного устройства /dev/initrd для двухфазовой загрузки системы.

Во время первой фазы ядро запускается и монтирует начальную корневую файловую систему из содержимого /dev/initrd (например, RAM-диска, инициализированного системным загрузчиком). Во время второй фазы из начального содержимого корневого устройства загружаются дополнительные драйверы и модули. После загрузки дополнительных модулей с другого устройства монтируется новая корневая файловая система (т.е., нормальная корневая файловая система).

### Выполнение загрузки
При загрузке с initrd система загружается следующим образом:

1.

Загрузчик загружает файл ядра и содержимое /dev/initrd в память.

2.

При запуске ядра, оно разархивирует и копирует содержимое устройства /dev/initrd на устройство /dev/ram0, а затем освобождает память, занятую /dev/initrd.

3.

Затем ядро монтирует устройство /dev/ram0 для чтения и записи в качестве начальной корневой файловой системы.

4.

Если заданная нормальная корневая файловая система также является начальной корневой файловой системой (например, /dev/ram0), то ядро переходит к последнему пункту для нормальной загрузки.

5.

Если в начальной корневой файловой системе находится исполняемый файл /linuxrc, то он исполняется с UID 0. Файл /linuxrc должен иметь разрешения на исполнение. Файл /linuxrc может быть любым допустимым исполняемым файлом, даже файлом сценария.

6.

Если /linuxrc не выполняется или когда /linuxrc заканчивает выполнение, монтируется нормальная корневая файловая система. Если /linuxrc завершается и имеется какая-либо файловая система, примонтированная к начальной корневой файловой системе, то поведение ядра НЕ ОПРЕДЕЛЕНО. Смотрите подробности о поведении текущей версии ядра в разделе ЗАМЕЧАНИЯ.

7.

Если в нормальной корневой файловой системе есть каталог /initrd, то устройство /dev/ram0 перемещается из / в /initrd. Иначе, если каталог /initrd не существует, то устройство /dev/ram0 размонтируется. При перемещении из / в /initrd устройство /dev/ram0 не размонтируется, и потому процессы, запущенные с /dev/ram0, продолжают выполняться. Если каталог /initrd не существует в нормальной корневой файловой системе и какие-либо процессы с /dev/ram0 продолжают выполняться после завершения /linuxrc, то поведение ядра НЕ ОПРЕДЕЛЕНО. Смотрите подробности о поведении текущей версии ядра в разделе ЗАМЕЧАНИЯ.

8.

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

### Параметры
При использовании initrd на загрузку ядра влияют следующие параметры системного загрузчика:

initrd=имя_файла

Определяет файл, который нужно загрузить в качестве содержимого /dev/initrd. Для LOADLIN это параметр командной строки. Для LILO вы должны использовать эту команду в файле настройки LILO — /etc/lilo.config. Имя файла, определяемое этим параметром, обычно является образом файловой системы, сжатым программой gzip.

noinitrd

Этот загрузочный параметр отменяет двухфазную процедуру загрузки. Ядро выполняет обычную процедуру загрузки так, если бы устройство /dev/initrd не было инициализировано. С этим параметром всё содержимое /dev/initrd, загруженное в память системным загрузчиком, сохраняется. Этот параметр разрешает устройству /dev/initrd содержать любые данные, не ограничиваясь образом файловой системы. Однако, устройство /dev/initrd доступно только для чтения и может быть прочитано только один раз после запуска системы.

root=имя_устройства

Определяет устройство, которое должно быть использовано в качестве нормальной корневой файловой системы. Для LOADLIN это параметр командной строки Для LILO этот параметр определяется во время загрузки или строкой в файле настройки LILO — /etc/lilo.config. Устройство, определяемое этим параметром, должно быть монтируемым устройством, имеющим подходящую корневую файловую систему.

### Смена нормальной корневой файловой системы
По умолчанию, для определения нормальной корневой файловой системы используются настройки ядра (например, установленные в файле ядра с помощью rdev(8) или на этапе сборки ядра) или параметр системного загрузчика. При монтировании нормальной корневой файловой системы по NFS для задания настроек NFS нужно использовать загрузочные параметры nfs_root_name и nfs_root_addrs. Дополнительную информацию об этом можно найти в файле документации к ядру Documentation/filesystems/nfs/nfsroot.txt (или Documentation/filesystems/nfsroot.txt в Linux 2.6.33). Также дополнительная информация по настройкам корневой файловой системы содержится в документации к LILO и LOADLIN.

Также сменить нормальное корневое устройство можно из /linuxrc. Для этого должен быть смонтирован каталог /proc. После монтирования /proc, сменить нормальное корневое устройство из /linuxrc можно записав настройки в proc-файлы /proc/sys/kernel/real-root-dev, /proc/sys/kernel/nfs-root-name и /proc/sys/kernel/nfs-root-addrs. Для смены физического корневого устройства из /linuxrc нужно записать номер нового устройства корневой файловой системы в /proc/sys/kernel/real-root-dev. Для смены корневой файловой системы NFS из /linuxrc нужно записать настройки NFS в файлы /proc/sys/kernel/nfs-root-name и /proc/sys/kernel/nfs-root-addrs, а затем записать 0xff (номер псевдо-NFS-устройства) в файл /proc/sys/kernel/real-root-dev. Так, например, следующие команды изменят нормальное корневое устройство на /dev/hdb1:

```
echo 0x365 >/proc/sys/kernel/real-root-dev
```

В качестве примера c NFS, следующие команды изменят нормальное корневое устройство на каталог NFS /var/nfsroot на NFS-сервере локальной сети с IP-адресом 193.8.232.7 для системы с IP-адресом 193.8.232.2 и именем 'idefix':

```
echo /var/nfsroot >/proc/sys/kernel/nfs-root-name
echo 193.8.232.2:193.8.232.7::255.255.255.0:idefix \

    >/proc/sys/kernel/nfs-root-addrs
echo 255 >/proc/sys/kernel/real-root-dev
```

Замечание: Файл /proc/sys/kernel/real-root-dev для смены корневой файловой системы больше не применяется. Современный метод смены корневой файловой системы описан в файле кода ядра Linux Documentation/admin-guide/initrd.rst (или Documentation/initrd.txt до Linux 4.10), а также в pivot_root(2) и pivot_root(8).

### Использование
Основной причиной реализации initrd стала потребность в настройках модулей ядра во время установки системы.

Возможный сценарий установки системы:

1.

Программа-загрузчик стартует с дискеты или другого носителя с минимальным ядром (например, включающим поддержку /dev/ram, /dev/initrd и файловой системы ext2) и загружает в /dev/initrd начальную файловую систему, сжатую программой gzip.

2.

Исполняемый файл /linuxrc определяет: (1) что необходимо, чтобы смонтировать нормальную корневую файловую систему (т.е., тип устройства, драйверы, файловую систему) и (2) носитель распространения (например, CD-ROM, сеть, лента, …). Для этого может быть задан вопрос пользователю, запущена автоматического определения или использован гибридный подход.

3.

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

4.

Исполняемый файл /linuxrc создаёт и заполняет корневую файловую систему (на этой стадии нормальная корневая файловая система ещё не является законченной системой).

5.

Исполняемый файл /linuxrc устанавливает /proc/sys/kernel/real-root-dev, размонтирует /proc, нормальную корневую файловую систему и все другие файловые системы, которые он монтировал, а затем завершает работу.

6.

Затем ядро монтирует нормальную корневую файловую систему.

7.

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

8.

Системный загрузчик настраивается так, чтобы загружать в /dev/initrd файловую систему с набором модулей, которые были использованы для запуска системы в первый раз (например, устройство /dev/ram0 может быть изменено, затем размонтировано и, наконец, образ записывается из /dev/ram0 в файл).

9.

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

Ключевая роль /dev/initrd в вышеописанном механизме — в повторном использовании данных настройки во время нормальных действий системы без необходимости начального выбора ядра, загрузки ядра большего размера или пересборки ядра.

Второй вариант, где пригодится initrd — установка Linux на системы с различными наборами оборудования в одной обслуживаемой сети. В таких случаях может быть желательно использовать лишь небольшой набор ядер (в идеале — одно) и поддерживать как можно меньше по объему специфических изменений под конкретные системы. В этом случае создайте общий файл со всеми необходимыми модулями. После этого будет разным только файл /linuxrc или файл, запускаемый /linuxrc.

Третий вариант — более удобные диски восстановления системы. Поскольку информация, например расположение раздела корневой файловой системы, не нужна во время начальной загрузки, загруженная с /dev/initrd система может использовать диалоговый режим и/или автоматическое определение с последующей, возможно, проверкой правильности.

И наконец, дистрибутивы Linux на CD-ROM могут использовать initrd для упрощения установки с CD-ROM. Дистрибутив может использовать LOADLIN для непосредственной загрузки /dev/initrd с CD-ROM без необходимости в дискетах. Дистрибутив также может использовать загрузочную дискету LILO и затем запускаться с помощью /dev/initrd с большего RAM-диска, находящегося на CD-ROM.

## ФАЙЛЫ
/dev/initrd

/dev/ram0

/linuxrc

/initrd

## ЗАМЕЧАНИЯ
1.

В текущем ядре все файловые системы, которые остаются смонтированными, когда /dev/ram0 перемещается из / в /initrd, остаются доступными. Между тем, элементы /proc/mounts не обновляются.

2.

В текущем ядре, если каталог /initrd не существует, то /dev/ram0 НЕ будет полностью размонтирован, если /dev/ram0 используется какими-либо процессами или на нём смонтирована какая-либо файловая система. Если /dev/ram0 НЕ размонтирован полностью, то /dev/ram0 остаётся в памяти.

3.

При использовании /dev/initrd не нужно полагаться на поведение, описанное ранее. Поведение ядра Linux может измениться в будущих версиях.

## СМОТРИТЕ ТАКЖЕ
chown(1), mknod(1), ram(4), freeramdisk(8), rdev(8)

Файл Documentation/admin-guide/initrd.rst (или Documentation/initrd.txt до Linux 4.10) из дерева исходного кода ядра Linux, документация к LILO, документация к LOADLIN, документация к SYSLINUX.


intro

title: intro(4)

summary: введение в специальные файлы

text:
# intro(4)

## ИМЯ
intro - введение в специальные файлы

## ОПИСАНИЕ
В разделе 4 описываются специальные файлы (устройств).

## ФАЙЛЫ
/dev/* — файлы устройств

## ЗАМЕЧАНИЯ

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

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


lirc

title: lirc(4)

summary: устройства lirc

text:
# lirc(4)

## ИМЯ
lirc - устройства lirc

## ОПИСАНИЕ
Символьные устройства /dev/lirc* предоставляют низкоуровневый двунаправленный интерфейс к аппаратуре с инфракрасным (IR) управлением. Большинство этих устройств может принимать данные, а не которые и отправлять. При приёме или отправке данных драйвер работает в двух различных режимах, в зависимости от имеющейся аппаратуры.

Некоторая аппаратура (обычно, ТВ-карты) декодирует IR-сигнал самостоятельно и выдаёт обработанные события о нажатых кнопках в виде значений сканкодов. Драйверы такой аппаратуры работают в режиме LIRC_MODE_SCANCODE. Обычно, такая аппаратура не поддерживает отправку IR-сигналов. Кроме того, она может декодировать ограниченный набор IR-протоколов, обычно, только определённых пультов, поставляющихся с ней в комплекте.

Другой вид аппаратуры выдаёт потоки длительностей наличия/отсутствия импульсов. Такие драйверы работают в режиме LIRC_MODE_MODE2. Иногда такая аппаратура также поддерживает отправку данных через IR. Она может использоваться с любым (почти) видом аппаратуры. Этот тип аппаратуры также можно использовать в режиме LIRC_MODE_SCANCODE, в этом случае сигнал декодируют декодеры ядра. Эти декодеры можно писать в расширенных BPF (смотрите bpf(2)) и присоединять к устройству lirc.

Команда ioctl LIRC_GET_FEATURES (смотрите далее) позволяет определить доступность приёма и отправки, режимы, а также другие возможности.

### Чтение входящих данных в режиме LIRC_MODE_MODE2
В режиме LIRC_MODE_MODE2 данные, возвращаемые read(2), представляют собой 32-битные значения длительностей наличия/отсутствуя импульсов. Время длительностей (микросекунды) кодируется в младших 24 битах. Старшими 8 битам определяется тип пакета:

LIRC_MODE2_SPACE

Значение представляет длительность отсутствия импульса (микросекунды).

LIRC_MODE2_PULSE

Значение представляет длительность импульса (микросекунды).

LIRC_MODE2_FREQUENCY

Значение представляет частоту (Гц); смотрите команду ioctl LIRC_SET_MEASURE_CARRIER_MODE.

LIRC_MODE2_TIMEOUT

Значение представляет длительность отсутствия импульса (микросекунды). Пакет описывает паузу; смотрите ioctl LIRC_SET_REC_TIMEOUT_REPORTS.

### Чтение входящих данных в режиме LIRC_MODE_SCANCODE
В режиме LIRC_MODE_SCANCODE данные, возвращаемые read(2) в структуре lirc_scancode, содержат декодированные нажатия кнопок. Сканкод сохраняется в поле scancode, а протокол IR — в rc_proto. В этом поле хранится одно из значений enum rc_proto.

### Запись выходных данных в режиме LIRC_MODE_PULSE
Данные, записываемые в символьное устройство с помощью write(2), представляют собой последовательность наличия/отсутствия импульсов в виде целых чисел. Импульсы и их отсутствие неявно разделяются только по их положению. Данные должны начинаться и заканчиваться импульсом, то есть всегда должно быть нечётное количество выборок. Функция write(2) блокирует выполнение до тех пор, пока данные не будут переданы аппаратурой. Если данных больше, чем аппаратура может послать, то write(2) завершается с ошибкой EINVAL.

### Запись выходных данных в режиме LIRC_MODE_SCANCODE
Данные, записываемые в символьные устройства, должны храниться в структуре lirc_scancode. Должны быть заполнены поля scancode и rc_proto, остальные должны быть равны 0. IR-кодировщики ядра преобразуют сканкод в импульсы и паузы. При некорректном протоколе, сканкоде или устройстве lirc передача невозможна.

## КОМАНДЫ IOCTL
Работа ioctl с устройствами LIRC ограничена определением struct file_operations функции ioctl, что даёт unsigned int для команды ioctl и unsigned long для аргумента. С целью переносимости ioctl между 32-битными и 64-битными архитектурами эти значения ограничены 32-битными значениями.

```
#include <linux/lirc.h>    /* но смотрите ДЕФЕКТЫ */
int ioctl(int fd, int cmd, ...);
```

Следующие команды ioctl можно использовать для тестирования или изменения определённых аппаратных настроек через lirc. Для многих команд требуется третий аргумент, обычно с типом int, который обозначается далее как val.

### Всегда поддерживаемые команды
Устройства /dev/lirc* всегда поддерживают следующие команды:

LIRC_GET_FEATURES (void)

Возвращает битовую маску возможностей; смотрите ВОЗМОЖНОСТИ.

Если устройство возвращает код ошибки после LIRC_GET_FEATURES, то можно считать, что это устройство не является lirc.

### Необязательные команды
Некоторые устройства lirc поддерживают команды, перечисленные ниже. Если не утверждается обратное, они завершаются с ошибкой ENOTTY, если операция не поддерживается, или с ошибкой EINVAL, если операция завершилась с ошибкой или указаны некорректные параметры. Если драйвер не анонсирует поддержку определённых возможностей, то вызов соответствующих ioctl завершается с ошибкой ENOTTY.

LIRC_GET_REC_MODE (void)

Если в устройстве lirc нет приёмника, то эта операция завершается ошибкой ENOTTY. В противном случае возвращается режим приёма, который может быть одним из:

LIRC_MODE_MODE2

Драйвер возвращает последовательность длительностей наличия/ отсутствуя импульсов.

LIRC_MODE_SCANCODE

Драйвер возвращает значения struct lirc_scancode, каждое из которых представляет декодированное нажатие кнопки.

LIRC_SET_REC_MODE (int)

Задаёт режим приёма. Значением val может быть LIRC_MODE_SCANCODE или LIRC_MODE_MODE2.Если в устройстве lirc нет приёмника, то эта операция завершается ошибкой ENOTTY.

LIRC_GET_SEND_MODE (void)

Возвращает режим передачи. Поддерживаются LIRC_MODE_PULSE и LIRC_MODE_SCANCODE. Если в устройстве lirc нет передатчика, то эта операция завершается ошибкой ENOTTY.

LIRC_SET_SEND_MODE (int)

Задаёт режим передачи. Значением val может быть LIRC_MODE_SCANCODE или LIRC_MODE_PULSE. Если в устройстве lirc нет передатчика, то эта операция завершается ошибкой ENOTTY.

LIRC_SET_SEND_CARRIER (int)

Задаёт частоту модуляции. Значением аргумента является частота (в Гц).

LIRC_SET_SEND_DUTY_CYCLE (int)

Задаёт скважность несущей частоты (carrier duty cycle). Значение val — число в диапазоне [0,100], описывающей ширину импульса в виде процента от всего сигнала. Значения 0 и 100 не несут какого-то особенного смысла, но зарезервированы для использования в будущем.

LIRC_GET_MIN_TIMEOUT (void), LIRC_GET_MAX_TIMEOUT (void)

В некоторых устройствах есть встроенные таймеры, которые можно использовать для обнаружения длительного отсутствия активности IR. Это может помочь lircd(8) обнаружить окончание сигнала IR и что можно запускать процесс декодирования. Такие операции возвращают целочисленные значения минимального/максимального периода ожидания, которое можно задать (в микросекундах). У некоторых устройств период ожидания нельзя изменить. В таких драйверах LIRC_GET_MIN_TIMEOUT и LIRC_GET_MAX_TIMEOUT возвращают ошибку ENOTTY.

LIRC_SET_REC_TIMEOUT (int)

Задаёт период неактивности IR в виде целого значения (микросекунды). Корректные значения должны находиться в пределах, полученных от LIRC_GET_MIN_TIMEOUT и LIRC_GET_MAX_TIMEOUT. Значение 0 (если поддерживается оборудованием) отключает все аппаратные ожидания и о данных сообщается сразу после появления. Если точное значение установить невозможно, то нужно указать следующее большее возможное значение.

LIRC_GET_REC_TIMEOUT (void)

Возвращает текущий период неактивности (в микросекундах). Доступен в Linux с версии 4.18.

LIRC_SET_REC_TIMEOUT_REPORTS (int)

Включает (val равно 1) или выключает пакеты об (val равно 0) ожидании в LIRC_MODE_MODE2. Работа этой операции в разных версиях ядра отличается:

- Начиная с Linux 4.16: каждый раз при открытии устройства lirc сообщения о неактивности по умолчанию включается для файлового дескриптора результата. Операцию LIRC_SET_REC_TIMEOUT можно использовать для выключения (и, если нужно, потом включить заново) ожидания на файловом дескрипторе.

- В Linux 4.15 и старее: сообщения о неактивности по умолчанию выключено и его включение (LIRC_SET_REC_TIMEOUT) на любом файловом дескрипторе, связанном с устройством lirc, привод к включению ожидания неактивности для всех файловых дескрипторов, которые ссылаются на устройство (пока неактивность не будет снова выключена).

LIRC_SET_REC_CARRIER (int)

Задаёт верхнюю границу несущей частоты приёмника (Гц). Смотрите LIRC_SET_REC_CARRIER_RANGE.

LIRC_SET_REC_CARRIER_RANGE (int)

Задаёт нижнюю границу несущей частоты приёмника (Гц). Для выполнения этой операции сначала нужно задать нижнюю границу с помощью ioctl LIRC_SET_REC_CARRIER_RANGE, а затем верхнюю границу с помощью ioctl LIRC_SET_REC_CARRIER.

LIRC_SET_MEASURE_CARRIER_MODE (int)

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

LIRC_GET_REC_RESOLUTION (void)

Возвращает точность разрешения драйвера (в микросекундах).

LIRC_SET_TRANSMITTER_MASK (int)

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

LIRC_SET_WIDEBAND_RECEIVER (int)

У некоторых устройств есть специальный широкополосный приёмник, который предназначен для обучения выводу существующего пульта. Данную ioctl можно использовать для включения (val равно 1) или отключения (val равно 0) этого свойства. Это может быть полезно для устройств с узкополосными приёмниками, которые не могут работать с некоторыми пультами. Широкополосные приёмники могут иметь большую точность. С другой стороны, их недостаток в меньшей дальности приёма.

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

## ВОЗМОЖНОСТИ
ioctl LIRC_GET_FEATURES возвращает битовую маску, описывающую свойства драйвера. В маске могут быть установлены следующие биты:

LIRC_CAN_REC_MODE2

Драйвер способен вести приём в режиме LIRC_MODE_MODE2.

LIRC_CAN_REC_SCANCODE

Драйвер способен вести приём в режиме LIRC_MODE_SCANCODE.

LIRC_CAN_SET_SEND_CARRIER

Драйвер поддерживает изменение частоты модуляции с помощью LIRC_SET_SEND_CARRIER.

LIRC_CAN_SET_SEND_DUTY_CYCLE

Драйвер поддерживает изменение опорного сигнала с помощью LIRC_SET_SEND_DUTY_CYCLE.

LIRC_CAN_SET_TRANSMITTER_MASK

Драйвер поддерживает изменение передатчика(ов) с помощью LIRC_SET_TRANSMITTER_MASK.

LIRC_CAN_SET_REC_CARRIER

Драйвер поддерживает установку частоты приёмной несущей с помощью LIRC_SET_REC_CARRIER. Из-за объединения драйверов в ядре версии 2.6.36 любое устройство lirc должно устанавливать LIRC_CAN_SET_REC_CARRIER_RANGE, если указано свойство LIRC_CAN_SET_REC_CARRIER.

LIRC_CAN_SET_REC_CARRIER_RANGE

Драйвер поддерживает LIRC_SET_REC_CARRIER_RANGE. Перед использованием ioctl LIRC_SET_REC_CARRIER для указания верхней границы,нужно вызвать ioctl LIRC_SET_REC_CARRIER_RANGE для указания нижней границы несущей.

LIRC_CAN_GET_REC_RESOLUTION

Драйвер поддерживает LIRC_GET_REC_RESOLUTION.

LIRC_CAN_SET_REC_TIMEOUT

Драйвер поддерживает LIRC_SET_REC_TIMEOUT.

LIRC_CAN_MEASURE_CARRIER

Драйвер поддерживает измерение частоты модуляции с помощью LIRC_SET_MEASURE_CARRIER_MODE.

LIRC_CAN_USE_WIDEBAND_RECEIVER

Драйвер поддерживает режим обучения с помощью LIRC_SET_WIDEBAND_RECEIVER.

LIRC_CAN_SEND_PULSE

Драйвер поддерживает отправку в режиме LIRC_MODE_SCANCODE или LIRC_MODE_SCANCODE.

## ДЕФЕКТЫ
Для использования этих устройств требуется заголовочный файл ядра lirc.h. Этот файл был недоступен до ядра версии 4.6. Пользователи старых ядер могут использовать файл с сайта http://www.lirc.org.

## СМОТРИТЕ ТАКЖЕ
ir-ctl(1), lircd(8), bpf(2)

https://www.kernel.org/doc/html/latest/media/uapi/rc/lirc-dev.html


loop

title: loop(4)

summary: закольцованные устройства

text:
# loop(4)

## ИМЯ
loop, loop-control - закольцованные устройства

## ОБЗОР
\#include <linux/loop.h>

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

```
$ dd if=/dev/zero of=file.img bs=1MiB count=10
$ sudo losetup /dev/loop4 file.img
$ sudo mkfs -t ext4 /dev/loop4
$ sudo mkdir /myloopdev
$ sudo mount /dev/loop4 /myloopdev
```

Другой пример смотрите в losetup(8).

Для шифрования и расшифровки каждому закольцованному устройству может быть назначена функция обмена.

Для закольцованного блочного устройства доступны следующие операции ioctl(2):

LOOP_SET_FD

Связывает закольцованное устройство с открытым файлом, чей файловый дескриптор передаётся в третьем аргументе ioctl(2).

LOOP_CLR_FD

Отвязывает закольцованное устройство от файлового дескриптора.

LOOP_SET_STATUS

Назначает состояние (передаваемое в третьем аргументе ioctl(2)) закольцованному устройству. Данный аргумент представляет собой указатель на структуру loop_info, определённую в <linux/loop.h> следующим образом:

```
struct loop_info {

    int           lo_number;            /* только чтение из ioctl */

    dev_t         lo_device;            /* только чтение из ioctl */

    unsigned long lo_inode;             /* только чтение из ioctl */

    dev_t         lo_rdevice;           /* только чтение из ioctl */

    int           lo_offset;

    int           lo_encrypt_type;

    int           lo_encrypt_key_size;  /* только запись ioctl */

    int           lo_flags;             /* только чтение из ioctl */

    char          lo_name[LO_NAME_SIZE];

    unsigned char lo_encrypt_key[LO_KEY_SIZE];

                                        /* только запись ioctl */

    unsigned long lo_init[2];

    char          reserved[4];
};

```

Типом шифрования (lo_encrypt_type) должно быть одно из значений: LO_CRYPT_NONE, LO_CRYPT_XOR, LO_CRYPT_DES, LO_CRYPT_FISH2, LO_CRYPT_BLOW, LO_CRYPT_CAST128, LO_CRYPT_IDEA, LO_CRYPT_DUMMY, LO_CRYPT_SKIPJACK или LO_CRYPT_CRYPTOAPI (начиная с Linux 2.6.0).

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

LO_FLAGS_READ_ONLY

Закольцованное устройство доступно только для чтения.

LO_FLAGS_AUTOCLEAR (начиная с Linux 2.6.25)

Закольцованное устройство автоматически уничтожится после закрытия.

LO_FLAGS_PARTSCAN (начиная с Linux 3.2)

Разрешено автоматическое сканирования разделов.

LOOP_GET_STATUS

Получить состояние закольцованного устройства. В третьем аргументе ioctl(2) должен быть задан указатель на структуру struct loop_info.

LOOP_CHANGE_FD (начиная с Linux 2.6.5)

Поменять источник данных (backing store) закольцованного устройства на новый файл, определяемый файловым дескриптором, указанным в третьем аргументе ioctl(2), представленный целым числом. Данная операция допустима только, если закольцованное устройство доступно только на чтение и новый источник данных имеет тот же размер и тип, использованный ранее.

LOOP_SET_CAPACITY (начиная с Linux 2.6.30)

Изменить размер используемого (live) закольцованного устройства. Можно изменить размер используемого источника данных, а затем применить эту операцию для того, чтобы драйвер закольцованных устройств учёл новый размер. У этой операции нет аргументов.

Начиная с Linux 2.6, появилось две новые операции ioctl(2):

LOOP_SET_STATUS64, LOOP_GET_STATUS64

Они подобны описанным выше LOOP_SET_STATUS и LOOP_GET_STATUS, но используют структуру loop_info64, в которой есть несколько дополнительных полей, а некоторым другим полям назначены типы с большим диапазоном значений:

```
struct loop_info64 {

    uint64_t lo_device;                   /* только чтение из ioctl */

    uint64_t lo_inode;                    /* только чтение из ioctl */

    uint64_t lo_rdevice;                  /* только чтение из ioctl */

    uint64_t lo_offset;

    uint64_t lo_sizelimit;/* в байтах, 0 == макс. доступный */

    uint32_t lo_number;                   /* только чтение из ioctl */

    uint32_t lo_encrypt_type;

    uint32_t lo_encrypt_key_size;         /* только запись из ioctl */

    uint32_t lo_flags;                    /* только чтение из ioctl */

    uint8_t  lo_file_name[LO_NAME_SIZE];

    uint8_t  lo_crypt_name[LO_NAME_SIZE];

    uint8_t  lo_encrypt_key[LO_KEY_SIZE]; /* только запись из ioctl */

    uint64_t lo_init[2];
};

```

### /dev/loop-control
Начиная с Linux 3.1, ядро предоставляет устройство /dev/loop-control, которое позволяет приложению динамически находить свободное устройство, добавлять и удалять закольцованные устройства из системы. Для выполнения этих операций сначала открывается /dev/loop-control, а затем выполняется одна из следующих операций ioctl(2):

LOOP_CTL_GET_FREE

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

LOOP_CTL_ADD

Добавляет новое закольцованное устройство; номер устройства передаётся в виде длинного целого в третьем аргументе ioctl(2). При успешном выполнении возвращается индекс устройства. Если устройство уже выделено, то вызов завершается с ошибкой EEXIST.

LOOP_CTL_REMOVE

Удаляет закольцованное устройство; номер устройства передаётся в виде длинного целого в третьем аргументе ioctl(2). При успешном выполнении возвращается номер устройства. Если устройство используется, то вызов завершается с ошибкой EBUSY.

## ФАЙЛЫ
/dev/loop*

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

## ПРИМЕР
Программа, представленная ниже, используется устройство /dev/loop-control для поиска свободного закольцованного устройства, открывает закольцованное устройство, открывает файл, который нужно использовать в качестве источника данных, и связывает закольцованное устройство с источником. Демонстрация работы программы:

```
$ dd if=/dev/zero of=file.img bs=1MiB count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00609385 s, 1.7 GB/s
$ sudo ./mnt_loop file.img
loopname = /dev/loop5
```

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

```
#include <fcntl.h>
#include <linux/loop.h>
#include <sys/ioctl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define errExit(msg)    do { perror(msg); exit(EXIT_FAILURE); \

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

    int loopctlfd, loopfd, backingfile;

    long devnr;

    char loopname[4096];

    if (argc != 2) {

        fprintf(stderr, "Использование: %s файл-источник\n", argv[0]);

        exit(EXIT_FAILURE);

    }

    loopctlfd = open("/dev/loop-control", O_RDWR);

    if (loopctlfd == -1)

        errExit("open: /dev/loop-control");

    devnr = ioctl(loopctlfd, LOOP_CTL_GET_FREE);

    if (devnr == -1)

        errExit("ioctl-LOOP_CTL_GET_FREE");

    sprintf(loopname, "/dev/loop%ld", devnr);

    printf("loopname = %s\n", loopname);

    loopfd = open(loopname, O_RDWR);

    if (loopfd == -1)

        errExit("open: loopname");

    backingfile = open(argv[1], O_RDWR);

    if (backingfile == -1)

        errExit("open: backing-file");

    if (ioctl(loopfd, LOOP_SET_FD, backingfile) == -1)

        errExit("ioctl-LOOP_SET_FD");

    exit(EXIT_SUCCESS);
}
```

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