делает пользовательскую программу, всегда используют системные вызовы для доступа к драйверу устройства
В такого рода вещи нельзя выполнить (pre|post)|(inst|rm) сценарии. (pre|post)|(inst|rm) сценарии должны быть идемпотентом и неинтерактивная.
Вместо этого что Вы хотите сделать, обеспечивают шаблон debconf, который требует, чтобы на вопросы ответили для пакета, который будет полностью установлен.
Если Вы хотите пример, посмотрите на sun-java* пакеты. Можно просмотреть шаблон debconf здесь: dlj.templates.
sun-java* пакеты конкретно представляют лицензию, которая должна быть утверждена, прежде чем Java будет установлен.
Вот другой вопрос о примере из шаблона (потому что лицензия каждый является слишком длинным для репродуцирования здесь):
Template: shared/accepted-sun-dlj-v1-1
Type: boolean
Default: false
_Description: Do you accept the DLJ license terms?
In order to install this package, you must accept the license terms, the
"Operating System Distributor License for Java" (DLJ), v1.1. Not accepting
will cancel the installation.
Templateимя объекта в debconf базе данных. Это должно быть уникально.Typeтип значения. В этом случае это - булевская переменная, означающая, что debconf спросит вопрос "да"/"нет".Defaultдает первоначально выбранный ответ при представлении пользователю (или ответ, автоматически выбранный, если приоритет не достаточно высок для вопроса, который будет замечен)._Descriptionзаголовок диалогового окна.- Остающимся является текст, представленный в диалоговом окне. Это должно быть расположено с отступом с одиночным пробелом.
- Шаблоны разделяются пустыми строками (т.е.
\n\n)
Для получения дополнительной информации см. debconf документацию спецификации Debian и Справочный отдел Разработчика 6.5.
Пользователь вызывает библиотечные функции, обернутые системными вызовами (сырой системный вызов встречается у обычного программиста довольно редко). Код модуля все равно работает в режиме кернела, поэтому в какой-то момент должен быть контекстный переключатель из пользовательского пространства в пространство ядра. В идеале большинство модулей будут использовать стандартизированные интерфейсы (узлы устройств, netlink сокеты, даже inet сокеты), так что взаимодействие со стороны пользователя будет осуществляться в основном через read() и write() системные вызовы (ioctl также достаточно распространено, так как охватывает "лишние" настройки, которые не попадают под стандартные системные вызовы). Буферы уменьшают количество вызовов, но в конце всегда есть системный вызов.
Модули ядра существуют в пространстве ядра и поэтому по определению требуют системных вызовов для доступа из пользовательского пространства, поэтому да в отношении их.
Однако можно создать драйверы пользовательского пространства, которые построены на основе какого-либо ядра, хотя, в конце концов, для работы они должны выполнять системные вызовы. Это возможно, например, с устройствами I 2 C; драйвер пользовательского пространства использует SMBus API ядра (все системные вызовы). В этом случае какое-то приложение может технически использовать некоторые средства драйвера без прохождения через систему, но если драйвер действительно должен взаимодействовать с оборудованием, он снова вызывает системные вызовы.
Также можно использовать mmap () (системный вызов) в / dev / mem , которая является системной памятью (см. man mem ) и, поскольку это включает в себя все пространство ядра, предоставляет доступ к оборудованию. Манипулирование этой картой не требует каких-либо дополнительных системных вызовов.Я считаю, что это необычный поступок, частично потому, что он обходит само ядро таким образом, который может быть нежелательным, а частично потому, что его переносимость с одной архитектуры на другую потребует избыточности 1 - так что это с большей вероятностью будет использоваться для взлома и экспериментов, чем развертывание драйверов в производственных системах.
Драйверы ядра могут предоставлять пользователю интерфейс на основе узла устройства, который может работать с использованием read () и write () , которые являются системными вызовами.
1. Если вы пишете обычный драйвер ядра или используете API пользовательской среды ядра, само ядро покрывает проблемы переносимости; вы можете придерживаться одной версии своего кода. Если вы используете метод отображения памяти, вам придется иметь разные версии вашего кода для каждой архитектуры (которая уже есть в ядре, следовательно, «избыточна»).