Архив форумов ЦИТФорума

[alexxxxxxxxxx]

Пишу под freeBSD дрова и столкнулся з задачкой. Если кто знает решение подскажите please.

А вот и задачка
Приложение вызывает read(). Этот вызов передается в драйвер и там обрабатывается. В это время приклодная программа спит до тех пор пока покаа драйвер не реализует этот
read(). Драйвер данные для read() берет из буфера, который должен быть предварительно заполнен через обработчик прерываний. Если буфер не полостью заполнен то возвращается как бы ошибка и сейчас по идее прикладная программа просто циклиться до момента пока буфер не заполнится и драйвер не вернет данные.
Можно ли это все сделать на уровне драйвера без зацикливания прикладной программы (т.е. чтобы прикладной процесс входил в состояние сна до тех пор пока read не выдаст аполненный буфер). Проблема возможно усложняется тем, что к драйверу могут обращаться два прикланых процесса. Проблема в том что если заблокировать код read() в драйвере (через вызов tsleep(addr)), то сможет ли потом другой процесс воспользоваться эим read() если буфер для этого процесса заполнен и готов к выдаче (т.е. read() контролирует разные буферы для разных файловых дескрипторов)

[Dmitry.Karpov http://www.]

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

[alexxxxxxxxxxx]

Это точно
Вот и я поэкспериментировав 2 часа обнаружил что read() в коде драйвера можно просто усыпить (причем он заснет только для процесса вызвавшего read(), дугой процесс может обратиться к read() и все сработает как необходимо для этого процесса - вот это блин по настоящему круто, а я думал что заснет весь код драйвера, ну кроме аппаратных прерываний)

Спасибо за совьет

Что касается сигналов, то можно ли как то обойти момент завершения прикладной программы когда она получает сигнал от драйвера, а обработчика этого сигнала она не имеет (ну в общем в принципе не знает что ей драйвер может посылать какие то сигналы)?

[Dmitry.Karpov http://www.]

По умолчанию на /proc монтируется псевдофайловая система, в которой можно узнать о процессе все (IMHO). Попробуй копнуть туда...

[alexxxxxxxx]

Сигнал не стандартный (пользовательский SIGUSR1), который можно игнорировать и прочее, но он зарезервирован системой именно для пользовательских сигналов.
А что именно содержит /proc когда запущен некоторый процесс (хотя бы в общем)?
Спасибо.

[alexxxxxxxxxxx]

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