пространство ядра -> пространство пользователя

Может помочь.

Understanding the Linux Kernel, 3rd Edition
Chapter 19. Process Communication

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

подробнее всё описано в linux device drivers. см. "kernel synchronization"

Наверно, имеется в виду "ch05 Concurrency and Race Conditions", где действительно идет речь о семафорах.

Я вот чего не понимаю: в ядре семафоры инициализируются следующим образом: void sema_init(struct semaphore *sem, int val)

А формат пользовательской функции получения идентификатора множества семафоров semget следующий:

int semget (key_t key, int nsems, int semflg)

Не могу понять, как их связать? При создании семафора в ядре получаем struct semaphore, как передать "указатель" на него пользователю?

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

// wbr

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

если файл не катит(хотя имхо это нормальный вариант), то кто мешает модулю предоставить определённый api юзерспейсу?

не понял ответа. мне нужно, чтобы по событию в kernel space запускалась функция в user space. как это можно реализовать через расширение api?

смотри в сторону inotify

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

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

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

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

зато по своей функциональности он с лихвой покроет все ваши текущие да и будущие хотелки. да и регистрация и обслуживание собственного символьного устройства - дело более чем доступное и вполне укладывается в 200 строк кода. примеров действительно масса включая различные драйвера в ядре и уже упомянутую книгу Linux Device Drivers.

"лучше час потерять зато потом за пять минут долететь" (c) мультик

// wbr

А через procfs ? Оно вроде возволяет такое делать, и интерфейс для ядра проще, чем создание устройства. http://www.linuxcenter.ru/lib/books/lkmpg.phtml#CHAPTER5 Ещё есть sysfs с аналогичное функциональностью и вроде оно продвинутей.

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

маленькое отступление - вопрос автору,
что за событие такое в драйвере ядра о котором
надо, но невозможно, сообщить в userspace ?

"может надо в консерватории что-то подправить?" (c) Жванецкий

у нас в драйвере есть события типа например "принят управляющий код", нужно сообщить о нем в userspace: тип события и его параметры (N кода и т.п.)

понятно. спасибо, буду реализовывать как файл устройства (или файл в fs proc, + и - еще не оценил)

вот что не могу понять: есть 2 приложения, которые хотят читать инфу из файла. оба открыли /dev/qwer, оба сделали poll. Эмм кстати, как драйвер узнает, что его ждут? При попытке read() сразу же вызывается зарегестрированная функция, а как быть с poll/select?

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

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

чем это плохо: пользовательскому ПО хочется предоставить большую простоту, чем заставлять его проверять семафор и читать shared memory. Может быть есть более простые решения?

все-таки, найдите время и почитайте Linux Device Drivers. там есть ответы на все вопросы, которые вы задали. с объяснениями, примерами и пр.

// wbr

ясно, спсибо)

Сигналить приложениям можно через DBus, как сделано в hal.

> у нас в драйвере есть события типа например "принят управляющий код"

ну дык и делайте стандартным образом :)
если это какая-нить контрольно-измерительная хрень, то это char-девайс и 
обычный сигнал о наступлении события и fcntl..
если есть протокол передачи - то это сеть и oob-данные

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

> обычный сигнал о наступлении события и fcntl

Сигнал? O_O

у нас сетевой драйвер, используются сетевые возможности (struct net_device) и т.д. Но отдельные события будем передавать через драйвер символьного файла. Расскажи плз, что за сигналы ты упомянул?

Сейчас гуглю oob-данные

> у нас сетевой драйвер, используются сетевые возможности (struct net_device) и т.д. Но отдельные события будем передавать через драйвер символьного файла.

тогда тебе скорее смотреть в сторону netlink. Или ethtool :)