Linux устройства ввода вывода

Драйверы устройств в Linux

Часть 9: Управление вводом / выводом в Linux

Оригинал: «Device Drivers, Part 9: I/O Control in Linux»
Автор: Anil Kumar Pugalia
Дата публикации: August 1, 2011
Перевод: Н.Ромоданов
Дата перевода: июнь 2012 г.

В этой статье, которая является частью серии статей о драйверах устройств в Linux, рассказывается о типичной реализации ioctl() и ее использовании в Linux.

«Дайте мне ноутбук и расскажите мне о том, что было на практических занятиях по интерфейсам аппаратного обеспечения x86, которые проходили в лаборатории драйверов устройств Linux, а также о том, что планируется на следующих занятиях» — воскликнула Светлана, раздраженная тем, что она оказалась на больничной койке из-за пищевого отравления на вечеринке.

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

Введение в ioctl()

Операция ввода/вывода Input/Output Control (кратко — ioctl) является общей операцией или системным вызовом, который используется в большинстве драйверов различных категорий. Это один из самых универсальных системных вызовов. Если нет какого-нибудь другого системного вызова, который соответствует определенному требованию, то пользуются только системным вызовом ioctl() .

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

Вопрос: как это все можно получить с помощью единственного прототипа функции? Хитрость заключается в использовании двух основных параметров: команды и аргумента. Командой является число, представляющее некоторую операцию. Аргумент представляет собой соответствующий параметр для этой операции. В реализации функции ioctl() есть переключатель switch … case для выбора реализации соответствующих функций конкретной команды. До недавнего времени в ядре Linux использовался следующий прототип:

Но, начиная с ядра 2.6.35, он изменился следующим образом:

Если требуется больше аргументов, то все они помещаются в структуру, и указатель на структуру становится ‘одним’ аргументом команды. Независимо от того, будет ли это целое число или указатель, аргумент в пространстве ядра рассматривается как длинное целое (long integer) и обрабатывается соответствующим образом.

Вызов ioctl() обычно реализуется как часть соответствующего драйвера, а затем точно также, как и в других системных вызовах, таких как open() , read() и т. д., соответствующим образом инициализуется указатель на функцию. Например, в символьных драйверах это будет поле указателя функции ioctl или unlocked_ioctl , которое должно быть инициализировано в struct file_operations .

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

Здесь параметр cmd точно такой же, как и в реализации ioctl() в драйвере, а переменная-аргумент construct (. ) используется в качестве способа передать в ioctl() драйвера аргумент любого типа (но только один). Другие параметры будут игнорироваться.

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

Запрос значений внутренних переменных драйвера

Чтобы лучше понять эту скучную теорию, которая объяснялась выше, далее приводится код уже ранее упоминавшегося примера «отладки драйвера». В этом драйвере есть три статические глобальные переменные: status , dignity и ego , к которым необходимо обратиться и, возможно, работать с ними из приложения. В заголовочном файле query_ioctl.h определены соответствующий тип команды и соответствующий тип аргумента команды. Ниже приводится листинг:

Если их использовать, то реализация ioctl() драйвера в query_ioctl.c будет выглядеть следующим образом:

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

Теперь над файлами query_app.c и query_ioctl.c выполните следующие операции:

• С помощью команды make соберите драйвер query_ioctl (файл query_ioctl.ko ) и приложение (файл query_app ). Используйте следующий файл Makefile:
• Загрузите драйвер с помощью команды insmod query_ioctl.ko .
  • ./query_app — чтобы отобразить значения переменных драйвера
  • ./query_app -c — чтобы очистить значения переменных драйвера
  • ./query_app -g — чтобы отобразить значения переменных драйвера
  • ./query_app -s — чтобы установить значения переменных драйвера (ранее операция не упоминалась)
• Выгрузите драйвер с помощью команды rmmod query_ioctl .

Определение команд ioctl()

«Время посещений закончилось» — крикнул охранник. Светлана поблагодарила своих друзей, поскольку она теперь смогла разобраться с большей частью кода, в том числе необходимого, как было сказано выше, для функции copy_to_user() . Но ей хотелось бы узнать о макросах _IOR , _IO и т.д., которые использовались в определениях команд query_ioctl.h . Как ранее уже упомимналось для команды ioctl() , это лишь обычные номера. Но теперь в соответствии с стандартом POSIX для octl можно с помощью различных макросов в виде таких чисел дополнительно кодировать некоторую полезную информацию, касающуюся команд. В стандарте говорится о номерах для 32-битовых команд, сформированных из четырех компонент и занимающих биты [31:0]:

1. Направление действия операции команды [биты 31:30] — чтение, запись, обе операции или ни одна из операций — заполняется соответствующим макросом ( _IOR , _IOW , _IOWR , _IO ).
2. Размер аргумента команды [биты 29:16] — вычисляется с помощью sizeof() для конкретного типа аргумента команды — третий аргумент этих макросов.
3. 8-битное магического числа [биты 15:8] — чтобы обеспечить относительную уникальность команды — как правило, символ ASCII (первый аргумент этих макросов).
4. Оригинальный номер команды [биты 7:0] — фактический номер команды (1, 2, 3, . ), определенный в соответствии с нашим требованием — второй аргумент этих макросов.

Детали реализации смотрите в заголовочном файле .

Источник

Система ввода-вывода ос linux.

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

Общие понятия и концепции

В ОС linux реализован особый подход к управлению устройствами ввода-вывода. Данный подход заключается в интегрировании всех устройств ввода-вывода, т.н. файловую систему в виде специальных файлов (special files). Каждому устройству ввода-вывода назначается маршрут. Обычно в каталоге /dev, например диск может иметь маршрут /dev/hd1, принтер /dev/lp. Доступ к этим специальным файлам осуществляется так же, как и к любым другим файлам. Для этого не требуется никаких специальных команд или системных вызовов, например cp f1 /dev/lp. Данная команда скопирует данный файл на принтер, в результате чего файл будет распечатан. Программы могут открывать, читать и записывать в специальные файлы. Существует 2 типа специальных файлов – блочные и символьные. Блочный специальный файл состоит из последовательности пронумерованных блоков. Основное свойство блочного специального файла заключается в том, что к каждому его блоку можно адресоваться и получить доступ. Программа может открыть блочный файл и получить доступ к произвольному пронумерованному блоку. Символьные специальные файлы используются для устройств ввода-вывода символьного потока (клавиатура, мышь, принтер, сети и т.д.). С каждым специальным файлом связан драйвер устройства, осуществляющий работу с соответствующим устройством. У каждого драйвера есть так называемый номер старшего устройства (major device). Если драйвер поддерживает несколько устройств одного типа, то каждому такому устройству присваивается номер младшего устройства(minor device). Вместе взятые номера главного устройства и младшего устройства однозначно определяют каждое устройство ввода вывода.

Работа с сетью:

При работе с сетевыми устройствами в системе linux ключевым понятием является сокет.

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

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

2. Надежный, ориентированный на соединение потоков пакетов. 2-й тип сокетов отличается от первого тем, что он сохраняет границы пакетов.

Каждый из вышерассмотренных типов сокетов гарантирует передачу данных.

3. Ненадежная передача пакетов.

Данный тип сокетов предоставляет пользователю прямой доступ к сети (без труб). Данный тип сокетов полезен для приложений реального времени, возможны потери пакетов и байтов или неверный их порядок. Основное преимущество – высокая производительность. При создании сокета, один из параметров указывает на используемый протокол. Для надежных байтовый потоков используется протокол TCP (Transmission Control Protocol). Для ненадежной передачи пакетов обычно применяется протокол UDP (User Data Protocol). Оба они работают поверх протокола IP. Прежде чем сокет может быть использован с ним должен быть связан адрес. Как только сокеты созданы на компьютере-источнике и на компьютере-приемнике, между ними может быть установлено соединение. Одна сторона делает системный вызов listen(A), указывая в качестве параметра локальный сокет. Другая сторона делает системный вызов connect(B, adress), задавая в параметрах дескриптор файла для локального сокета и адрес для удаленного сокета. Если удаленный компьютер принимает вызов, то система устанавливает соединение между двумя сокетами. После установления соединения оно работает по аналогичному каналу для того, чтобы закрыть данный канал используется системный вызов close.

Опора деревянной одностоечной и способы укрепление угловых опор: Опоры ВЛ — конструкции, предназначен­ные для поддерживания проводов на необходимой высоте над землей, водой.

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

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

Источник

Linux устройства ввода вывода

В языке C для осуществления файлового ввода-вывода используются механизмы стандартной библиотеки языка, объявленные в заголовочном файле stdio.h. Как вы вскоре узнаете консольный ввод-вывод — это не более чем частный случай файлового ввода-вывода. В C++ для ввода-вывода чаще всего используются потоковые типы данных. Однако все эти механизмы являются всего лишь надстройками над низкоуровневыми механизмами ввода-вывода ядра операционной системы.

С точки зрения модели КИС (Клиент-Интерфейс-Сервер), сервером стандартных механизмов ввода вывода языка C (printf, scanf, FILE*, fprintf, fputc и т. д.) является библиотека языка. А сервером низкоуровневого ввода-вывода в Linux, которому посвящена эта глава книги, является само ядро операционной системы.

Пользовательские программы взаимодействуют с ядром операционной системы посредством специальных механизмов, называемых системными вызовами (system calls, syscalls). Внешне системные вызовы реализованы в виде обычных функций языка C, однако каждый раз вызывая такую функцию, мы обращаемся непосредственно к ядру операционной системы. Список всех системных вызовов Linux можно найти в файле /usr/include/asm/unistd.h. В этой главе мы рассмотрим основные системные вызовы, осуществляющие ввод-вывод: open(), close(), read(), write(), lseek() и некоторые другие.

5.2. Файловые дескрипторы

В языке C при осуществлении ввода-вывода мы используем указатель FILE*. Даже функция printf() в итоге сводится к вызову vfprintf(stdout. ), разновидности функции fprintf(); константа stdout имеет тип struct _IO_FILE*, синонимом которого является тип FILE*. Это я к тому, что консольный ввод-вывод — это файловый ввод-вывод. Стандартный поток ввода, стандартный поток вывода и поток ошибок (как в C, так и в C++) — это файлы. В Linux все, куда можно что-то записать или откуда можно что-то прочитать представлено (или может быть представлено) в виде файла. Экран, клавиатура, аппаратные и виртуальные устройства, каналы, сокеты — все это файлы. Это очень удобно, поскольку ко всему можно применять одни и те же механизмы ввода-вывода, с которыми мы и познакомимся в этой главе. Владение механизмами низкоуровневого ввода-вывода дает свободу перемещения данных в Linux. Работа с локальными файловыми системами, межсетевое взаимодействие, работа с аппаратными устройствами, — все это осуществляется в Linux посредством низкоуровневого ввода-вывода.

Вы уже знаете из предыдущей главы, что при запуске программы в системе создается новый процесс (здесь есть свои особенности, о которых пока говорить не будем). У каждого процесса (кроме init) есть свой родительский процесс (parent process или просто parent), для которого новоиспеченный процесс является дочерним (child process, child). Каждый процесс получает копию окружения (environment) родительского процесса. Оказывается, кроме окружения дочерний процесс получает в качестве багажа еще и копию таблицы файловых дескрипторов.

Файловый дескриптор (file descriptor) — это целое число (int), соответствующее открытому файлу. Дескриптор, соответствующий реально открытому файлу всегда больше или равен нулю. Копия таблицы дескрипторов (читай: таблицы открытых файлов внутри процесса) скрыта в ядре. Мы не можем получить прямой доступ к этой таблице, как при работе с окружением через environ. Можно, конечно, кое-что «вытянуть» через дерево /proc, но нам это не надо. Программист должен лишь понимать, что каждый процесс имеет свою копию таблицы дескрипторов. В пределах одного процесса все дескрипторы уникальны (даже если они соответствуют одному и тому же файлу или устройству). В разных процессах дескрипторы могут совпадать или не совпадать — это не имеет никакого значения, поскольку у каждого процесса свой собственный набор открытых файлов.

Возникает вопрос: сколько файлов может открыть процесс? В каждой системе есть свой лимит, зависящий от конфигурации. Если вы используете bash или ksh (Korn Shell), то можете воспользоваться внутренней командой оболочки ulimit, чтобы узнать это значение. Если вы работаете с оболочкой C-shell (csh, tcsh), то в вашем распоряжении команда limit:

В командной оболочке, в которой вы работаете (bash, например), открыты три файла: стандартный ввод (дескриптор 0), стандартный вывод (дескриптор 1) и стандартный поток ошибок (дескриптор 2). Когда под оболочкой запускается программа, в системе создается новый процесс, который является для этой оболочки дочерним процессом, следовательно, получает копию таблицы дескрипторов своего родителя (то есть все открытые файлы родительского процесса). Таким образом программа может осуществлять консольный ввод-вывод через эти дескрипторы. На протяжении всей книги мы будем часто играть с этими дескрипторами.

Таблица дескрипторов, помимо всего прочего, содержит информацию о текущей позиции чтения-записи для каждого дескриптора. При открытии файла, позиция чтения-записи устанавливается в ноль. Каждый прочитанный или записанный байт увеличивает на единицу указатель текущей позиции. Мы вернемся к этой теме в разделе 5.7.

5.3. Открытие файла: системный вызов open()

Чтобы получить возможность прочитать что-то из файла или записать что-то в файл, его нужно открыть. Это делает системный вызов open(). Этот системный вызов не имеет постоянного списка аргументов (за счет использования механизма va_arg); в связи с этим существуют две «разновидности» open(). Не только в С++ есть перегрузка функций 😉 Если интересно, то о механизме va_arg можно прочитать на man-странице stdarg (man 3 stdarg) или в книге Б. Кернигана и Д. Ритчи «Язык программирования Си». Ниже приведены адаптированные прототипы системного вызова open().

Системный вызов open() объявлен в заголовочном файле fcntl.h. Ниже приведен общий адаптированный прототип open().

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

Второй аргумент — это режим открытия файла, представляющий собой один или несколько флагов открытия, объединенных оператором побитового ИЛИ. Список доступных флагов приведен в Таблице 4 Приложения 2.. Наиболее часто используют только первые семь флагов. Если вы хотите, например, открыть файл в режиме чтения и записи, и при этом автоматически создать файл, если такового не существует, то второй аргумент open() будет выглядеть примерно так: O_RDWR|O_CREAT. Константы-флаги открытия объявлены в заголовочном файле bits/fcntl.h, однако не стоит включать этот файл в свои программы, поскольку он уже включен в файл fcntl.h.

Третий аргумент используется в том случае, если open() создает новый файл. В этом случае файлу нужно задать права доступа (режим), с которыми он появится в файловой системе. Права доступа задаются перечислением флагов, объединенных побитовым ИЛИ. Вместо флагов можно использовать число (как правило восьмиричное), однако первый способ нагляднее и предпочтительнее. Список флагов приведен в Таблице 1 Приложения 2. Чтобы, например, созданный файл был доступен в режиме «чтение-запись» пользователем и группой и «только чтение» остальными пользователями, — в третьем аргументе open() надо указать примерно следующее: S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH или 0664. Флаги режима доступа реально объявлены в заголовочном файле bits/stat.h, но он не предназначен для включения в пользовательские программы, и вместо него мы должны включать файл sys/stat.h. Тип mode_t объявлен в заголовочном файле sys/types.h.

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

5.4. Закрытие файла: системный вызов close()

Системный вызов close() закрывает файл. Вообще говоря, по завершении процесса все открытые файлы (кроме файлов с дескрипторами 0, 1 и 2) автоматически закрываются. Тем не менее, это не освобождает нас от самостоятельного вызова close(), когда файл нужно закрыть. К тому же, если файлы не закрывать самостоятельно, то соответствующие дескрипторы не освобождаются, что может привести к превышению лимита открытых файлов. Простой пример: приложение может быть настроено так, чтобы каждую минуту открывать и перечитывать свой файл конфигурации для проверки обновлений. Если каждый раз файл не будет закрываться, то в моей системе, например, приложение может «накрыться медным тазом» примерно через 17 часов. Автоматически! Кроме того, файловая система Linux поддерживает механизм буферизации. Это означает, что данные, которые якобы записываются, реально записываются на носитель (синхронизируются) только через какое-то время, когда система сочтет это правильным и оптимальным. Это повышает производительность системы и даже продлевает ресурс жестких дисков. Системный вызов close() не форсирует запись данных на диск, однако дает больше гарантий того, что данные останутся в целости и сохранности.

Системный вызов close() объявлен в файле unistd.h. Ниже приведен его адаптированный прототип.

Очевидно, что единственный аргумент — это файловый дескриптор. Возвращаемое значение — ноль в случае успеха, и -1 — в случае ошибки. Довольно часто close() вызывают без проверки возвращаемого значения. Это не очень грубая ошибка, но, тем не менее, иногда закрытие файла бывает неудачным (в случае неправильного дескриптора, в случае прерывания функции по сигналу или в случае ошибки ввода-вывода, например). В любом случае, если программа сообщит пользователю, что файл невозможно закрыть, это хорошо.

Теперь можно написать простенкую программу, использующую системные вызовы open() и close(). Мы еще не умеем читать из файлов и писать в файлы, поэтому напишем программу, которая создает файл с именем, переданным в качестве аргумента (argv[1]) и с правами доступа 0600 (чтение и запись для пользователя). Ниже приведен исходный код программы.

Обратите внимание, если запустить программу дважды с одним и тем же аргументом, то на второй раз open() выдаст ошибку. В этом виноват флаг O_EXCL (см. Таблицу 4 Приложения 2), который «дает добро» только на создание еще не существующих файлов. Наглядности ради, флаги открытия и флаги режима мы занесли в отдельные переменные, однако можно было бы сделать так: Или так:

5.5. Чтение файла: системный вызов read()

Системный вызов read(), объявленный в файле unistd.h, позволяет читать данные из файла. В отличие от библиотечных функций файлового ввода-вывода, которые предоставляют возможность интерпретации считываемых данных. Можно, например, записать в файл следующее содержимое:

Теперь, используя библиотечные механизмы, можно читать файл по-разному:

Системный вызов read() читает данные в «сыром» виде, то есть как последовательность байт, без какой-либо интерпретации. Ниже представлен адаптированный прототип read().

Первый аргумент — это файловый дескриптор. Здесь больше сказать нечего. Второй аргумент — это указатель на область памяти, куда будут помещаться данные. Третий аргумент — количество байт, которые функция read() будет пытаться прочитать из файла. Возвращаемое значение — количество прочитанных байт, если чтение состоялось и -1, если произошла ошибка. Хочу заметить, что если read() возвращает значение меньше count, то это не символизирует об ошибке.

Хочу сказать несколько слов о типах. Тип size_t в Linux используется для хранения размеров блоков памяти. Какой тип реально скрывается за size_t, зависит от архитектуры; как правило это unsigned long int или unsigned int. Тип ssize_t (Signed SIZE Type) — это тот же size_t, только знаковый. Используется, например, в тех случаях, когда нужно сообщить об ошибке, вернув отрицательный размер блока памяти. Системный вызов read() именно так и поступает.

Теперь напишем программу, которая просто читает файл и выводит его содержимое на экран. Имя файла будет передаваться в качестве аргумента (argv[1]). Ниже приведен исходный код этой программы.

В этом примере используется укороченная версия open(), так как файл открывается только для чтения. В качестве буфера (второй аргумент read()) мы передаем адрес переменной типа char. По этому адресу будут считываться данные из файла (по одному байту за раз) и передаваться на стандартный вывод. Цикл чтения файла заканчивается, когда read() возвращает нуль (нечего больше читать) или -1 (ошибка). Системный вызов close() закрывает файл.

Как можно заметить, в нашем примере системный вызов read() вызывается ровно столько раз, сколько байт содержится в файле. Иногда это действительно нужно; но не здесь. Чтение-запись посимвольным методом (как в нашем примере) значительно замедляет процесс ввода-вывода за счет многократных обращений к системным вызовам. По этой же причине возрастает вероятность возникновения ошибки. Если нет действительной необходимости, файлы нужно читать блоками. О том, какой размер блока предпочтительнее, будет рассказано в последующих главах книги. Ниже приведен исходный код программы, которая делает то же самое, что и предыдущий пример, но с использованием блочного чтения файла. Размер блока установлен в 64 байта.

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

5.6. Запись в файл: системный вызов write()

Для записи данных в файл используется системный вызов write(). Ниже представлен его прототип.

Как видите, прототип write() отличается от read() только спецификатором const во втором аргументе. В принципе write() выполняет процедуру, обратную read(): записывает count байтов из буфера buffer в файл с дескриптором fd, возвращая количество записанных байтов или -1 в случае ошибки. Так просто, что можно сразу переходить к примеру. За основу возьмем программу myread1 из предыдущего раздела.

В этом примере нам уже не надо изощеряться в попытках вставить нуль-терминатор в строку для записи, поскольку системный вызов write() не запишет большее количество байт, чем мы ему указали. В данном случае для демонстрации write() мы просто записывали данные в файл с дескриптором 1, то есть в стандартный вывод. Но прежде, чем переходить к чтению следующего раздела, попробуйте самостоятельно записать что-нибудь (при помощи write(), естественно) в обычный файл. Когда будете открывать файл для записи, обратите пожалуйста внимание на флаги O_TRUNC, O_CREAT и O_APPEND. Подумайте, все ли флаги сочетаются между собой по смыслу.

5.7. Произвольный доступ: системный вызов lseek()

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

Для изменения текущей позиции чтения-записи используется системный вызов lseek(). Ниже представлен его прототип.

Первый аргумент, как всегда, — файловый дескриптор. Второй аргумент — смещение, как положительное (вперед), так и отрицательное (назад). Третий аргумент обычно передается в виде одной из трех констант SEEK_SET, SEEK_CUR и SEEK_END, которые показывают, от какого места отсчитывается смещение. SEEK_SET — означает начало файла, SEEK_CUR — текущая позиция, SEEK_END — конец файла. Рассмотрим следующие вызовы:

Первый вызов устанавливает текущую позицию в начало файла. Второй вызов смещает позицию вперед на 20 байт. В третьем случае текущая позиция перемещается на 10 байт назад относительно конца файла.

В случае удачного завершения, lseek() возвращает значение установленной «новой» позиции относительно начала файла. В случае ошибки возвращается -1.

Я долго думал, какой бы пример придумать, чтобы продемонстрировать работу lseek() наглядным образом. Наиболее подходящим примером мне показалась идея создания программы рисования символами. Программа оказалась не слишком простой, однако если вы сможете разобраться в ней, то можете считать, что успешно овладели азами низкоуровневого ввода-вывода Linux. Ниже представлен исходный код этой программы.

Теперь разберемся, как работает эта программа. Изначально «полотно» заполняется пробелами. Функция init_draw() построчно записывает в файл пробелы, чтобы получился «холст», размером N_ROWS на N_COLS. Массив строк icode в функции main() — это набор команд рисования. Команда начинается с одной из трех литер: ‘v’ — нарисовать вертикальную линию, ‘h’ — нарисовать горизонтальную линию, ‘p’ — нарисовать точку. После каждой такой литеры следуют три числа. В случае вертикальной линии первое число — фиксированная координата X, а два других числа — это начальная и конечная координаты Y. В случае горизонтальной линии фиксируется координата Y (первое число). Два остальных числа — начальная координата X и конечная координата X. При рисовании точки используются только два первых числа: координата X и координата Y. Итак, функция draw_vline() рисует вертикальную линию, функция draw_hline() рисует горизонтальную линию, а draw_point() рисует точку.

Функция init_draw() пишет в файл N_ROWS строк, каждая из которых содержит N_COLS пробелов, заканчивающихся переводом строки. Это процедура подготовки «холста».

Функция draw_point() вычисляет позицию (исходя из значений координат), перемещает туда текущую позицию ввода-вывода файла, и записывает в эту позицию символ (FG_CHAR), которым мы рисуем «картину».

Функция draw_hline() заполняет часть строки символами FG_CHAR. Так получается горизонтальная линия. Функция draw_vline() работает иначе. Чтобы записать вертикальную линию, нужно записывать по одному символу и каждый раз «перескакивать» на следующую строку. Эта функция работает медленнее, чем draw_hline(), но иначе мы не можем.

Полученное изображение записывается в файл image. Будьте внимательны: чтобы разгрузить исходный код, из программы исключены многие проверки (read(), write(), close(), диапазон координат и проч.). Попробуйте включить эти проверки самостоятельно.

Источник