Компилирую драйвер под ядро 2.6 Использую следующий Makefile:

DEBUG = y

ifeq ($(DEBUG),y) DEBFLAGS = -O -g -DWCBA_DEBUG else DEBFLAGS = -O2 endif

CFLAGS += $(DEBFLAGS)

ifneq ($(KERNELRELEASE),) obj-m := wcba.o

else

KERNELDIR ?= /lib/modules/$(shell uname -r)/build PWD := $(shell pwd)

default: $(MAKE) -C $(KERNELDIR) M=$(PWD) modules endif

Драйвер компилится в текущий каталог. Как указать, чтобы объектный файл драйвера собирался в каталоге, ну скажем ../../../sys

Конфигурация:

Debian Linux, ядро 2.6.8-3-386, установленное из пакета kernel-image-2.6-386.

Для сборки драйвера установил пакеты kernel-headers-2.6-386 kernel-headers-2.6.8-3 kernel-headers-2.6.8-3-386 kernel-kbuild-2.6.3

Вроде всё как написано в третьем издании Linux Device Drivers

Сделал Makefile:

ifneq ($(KERNELRELEASE),)

obj-m := main.c

else

KERNELDIR ?= /lib/modules/$(shell uname -r)/build PWD := $(shell pwd)

default: $(MAKE) -C $(KERNELDIR) M=$(PWD) modules

endif

Выполнил make и получил:

pc7:/home/snilga/3w/drivers/linux/wcba/src/sys/2.6# make

make -C /lib/modules/2.6.8-3-386/build M=/home/snilga/3w/drivers/linux/wcba/src/sys/2.6 modules make[1]: Entering directory `/usr/src/kernel-headers-2.6.8-3-386' scripts/Makefile.build:176: цель `/home/snilga/3w/drivers/linux/wcba/src/sys/2.6/main.c' не соответствует образцу целей Building modules, stage 2. MODPOST make[1]: Leaving directory `/usr/src/kernel-headers-2.6.8-3-386'

Объектный файл драйвера не создался (по крайней мере в моем каталоге). Может кто знает - в чем может быть дело?

Возникла проблема при компиляции драйвера собственной разработки в

Debian Linux 3.1 kernel 2.4.27-10

Ранее этот же драйвер я нормально компилировал в RedHat Linux с ядром 2.4.9-13

Проблема в Makefile. Я не большой знаток Linux, Makefile при компиляции в RedHat брал из книги Linux Device Drivers 2nd ed. Для настройки всевозможных флагов компиляции и определений там использовались строки типа

KERNELDIR = /usr/src/linux-2.4.9-13

include $(KERNELDIR)/configs/kernel-2.4.9-i686.config

Однако при компиляции в Debian обнаружил, что разработчики Debian Linux куда-то дели каталог configs из исходников ядра.

Подскажите пожалуйста, откуда в Debian брать настройки для компилятора и линкера в Makefile. Если кто поделится примером простенького работающего Makefile для компиляции драйвера - тоже не обижусь :-)

Может кто знает, есть ли для Linux реализация клиентов OPC или NetDDE?

Народ, подскажите где взять нормальную доку по работе с COM-портами в UNIX (конкретно Solaris 8). По манам там полгода разбираться.

Надо из сишной проги запустить на выполнение скрипт, но не просто запустить, а вывод этого скрипта получить в вызывающей проге. Как?

Варианты типа "перенаправить вывод в файл, а потом его прочитать" просьба не предлагать :-)

В идеале хочется получить доступ к потокам ввода и вывода запускаемого скрипта.

Кто-нить знает, как сымитировать программно нажатие клавиши (комбинации клавиш) клавиатуры средствами Linux или X11?

В случае: если параметры передаются по одному, объявление и передача параметров драйверу выглядит так:

//Обявление

int param_ival=0; MODULE_PARM (param_ival, "i");

// Передача

insmod mydriver.o param_ival=5

А если у меня параметр - массив строк, объявление в драйвере:

char* param_sval[10];

MODULE_PARM (param_sval, "1-10s");

А как при вызове insmod передать драйверу этот массив?

В bash-скрипте надо просмотреть все файлы (бинарные) из каталога /proc/bus/pci/ и сформировать список файлов, в которых встречается заданная последовательность байт.

Другими словами, надо найти все PCI устройства определенного типа по вендору изготовителя, а файлы в каталоге /proc/bus/pci содержат информацию из конигурационных регистров всех PCI железок в системе.

Как это сделать?

Red Hat Linux, ядро 2.4.9-13.

Пишу драйвер для PCI устройства (вставляется в слот PCI). Таких устройств может быть несколько (до 10). Проблема с идентификацией устройств в системе.

Сейчас драйвер нумерует устройства в цикле, в порядке обнаружения их функцией pci_find_subsys() (например /dev/d0, /dev/d1 и т.д.). Это плохо, так как при изъятии скажем нулевого устройства, первое становится нулевым, а первого вообще не будет.

Такого понятия как слот в линухе как я понял нет (Например в Solaris для Sun Sparc можно спокойно называть устройства в соответствии с номерами слотов PCI, подписанными на материнке).

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

Модульный драйвер под ядро 2-4-9-13 (RedHat Linux)

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

typedef struct {

int kz;

unsigned short us;

unsigned short dl;

unsigned short dusp;

unsigned short *buf_in;

unsigned short *buf_out;

}KCO_PARAM;

В драйвере надо читать и писать в эти буферы. Как получить к ним доступ в драйвере?

copy_from_user и copy_to_user работает для структуры (значения всех полей передаются нормально), но не работает для полей buf_in и buf_out (т.е. не получается скопировать в/из буфера по адресу buf_in и buf_uot используя copy_from_user и copy_to_user). Как преобразовать значения buf_in и buf_out и получить доступ к буферам из драйвера?

RedHat Linux c ядром 2.4.9-13 Есть железо для обмена данными между персоналкой и старой СМ-2М

Написал драйвер, поддерживающий операции read(), write(). Логический протокол обмена, состоящий из запросов к СМ-2М, получения и отправки данных и подтверждений реализовал в обычном приложении.

Но оказалось, что все это не работает под Linux и вот почему. Посылаю запрос к СМ-2М вызовом write() из программы, потом по протоколу должен получить подтверждение от СМ-2М, то есть вызвать read(). Но если планировщик задач снимает мою задачу с выполнения, то задержка между моим write() и read() где-то 100 мс (проверял на осцилографе :-)). А в СМ-2М таймаут 30 мс. Так что, если моя задача снимается с выполнения, то весь обмен накрывается.

Вижу три выхода:

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

2. Попытаться скомпилировать ядро с меньшим тактом работы планировщика (10 мс.) Но заказчик упирается рогами и говорит что это не выход. Думаю, он прав

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

Нашел в форуме диалог по интересующей меня проблеме, но не доведенный до конца.

Надо связаться с инициатором разговора. Это можно как-нибудь сделать?

rh linux, ядро 2.4.9-13

Проблема с установкой собственного драйвера.

Попробовал запустить depmod, и на своем драйвере получил:

#depmod

#depmod:***Unresolved sumbols in /lib/modules/2.4.9-13/kernel/drivers/char/mppa.o

хотя modprobe и insmod отрабатывают нормально...

А как узнать, чего именно не хватает в драйвере для depmod?

У меня определена следующая информация:

static struct pci_device_id mppa_id_table[]={

{MPPA_VENDOR_ID,MPPA_DEVICE_ID,MPPA_SUBSYSTEM_ID,MPPA_SUBSYSTEM_VENDOR_ID,0,0,},

{0,}

};

MODULE_DEVICE_TABLE(pci,mppa_id_table);

MODULE_AUTHOR("Sergey Nilga");

MODULE_DESCRIPTION("Westron MPP-A module");

MODULE_LICENSE("GPL");

MODULE_SUPPORTED_DEVICE("mppa");

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

Надо по-быстрому написать консольное приложение, в котором должны отображаться данные в виде таблицы. Как перемещать курсор по вертикали в консольном приложении? Слышал что есть библиотека cursors, но не знаю, где взять help по функциям.

Поставил RH Linux 7.1 c ядром 2.4.2-2 и X11R6 4.0.3. Драйвера под мою видеокарту (intel 830/840/845 G/GL) там понятное дело не оказалось. пытался натянуть драйвер vesa, при запуске в логе иксов получил:

(II) VESA(0): VESA BIOS detected (II) VESA(0): VESA VBE Version 3.0 (II) VESA(0): VESA VBE Total Mem: 8000 kB (II) VESA(0): VESA VBE OEM: Brookdale-G Graphics Chip Accelerated VGA BIOS (II) VESA(0): VESA VBE OEM Software Rev: 1.0 (II) VESA(0): VESA VBE OEM Vendor: Intel Corporation (II) VESA(0): VESA VBE OEM Product: Brookdale-G Graphics Controller (II) VESA(0): VESA VBE OEM Product Rev: Hardware Version 0.0 (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Loading /usr/X11R6/lib/modules/libddc.a (II) Module ddc: vendor="The XFree86 Project" compiled for 4.0.3, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.3 (II) VESA(0): VESA VBE DDC supported (II) VESA(0): VESA VBE DDC Level 2 (II) VESA(0): VESA VBE DDC transfer in appr. 1 sec. (II) VESA(0): VESA VBE DDC read successfully (II) VESA(0): Manufacturer: VSC Model: 4208 Serial#: 16843009 (II) VESA(0): Year: 2003 Week: 16 (II) VESA(0): EDID Version: 1.3 (II) VESA(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V (II) VESA(0): Sync: Separate Composite SyncOnGreen (II) VESA(0): Max H-Image Size [cm]: horiz.: 41 vert.: 31 (II) VESA(0): Gamma: 2.20 (II) VESA(0): DPMS capabilities: Off; RGB/Color Display (II) VESA(0): First detailed timing is preferred mode (II) VESA(0): redX: 0.647 redY: 0.346 greenX: 0.298 greenY: 0.591 (II) VESA(0): blueX: 0.150 blueY: 0.118 whiteX: 0.313 whiteY: 0.329 (II) VESA(0): Supported VESA Video Modes: (II) VESA(0): 720x400@70Hz (II) VESA(0): 640x480@60Hz (II) VESA(0): 640x480@67Hz (II) VESA(0): 640x480@72Hz (II) VESA(0): 640x480@75Hz (II) VESA(0): 800x600@56Hz (II) VESA(0): 800x600@60Hz (II) VESA(0): 800x600@72Hz (II) VESA(0): 800x600@75Hz (II) VESA(0): 832x624@75Hz (II) VESA(0): 1024x768@60Hz (II) VESA(0): 1024x768@70Hz (II) VESA(0): 1024x768@75Hz (II) VESA(0): 1280x1024@75Hz (II) VESA(0): 1152x870@75Hz (II) VESA(0): Manufacturer's mask: 0 (II) VESA(0): Supported Future Video Modes: (II) VESA(0): #0: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 (II) VESA(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) VESA(0): #2: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) VESA(0): #3: hsize: 1024 vsize 768 refresh: 85 vid: 22881 (II) VESA(0): #4: hsize: 800 vsize 600 refresh: 85 vid: 22853 (II) VESA(0): #5: hsize: 640 vsize 480 refresh: 85 vid: 22833 (II) VESA(0): Supported additional Video Mode: (II) VESA(0): clock: 162.0 MHz Image Size: 408 x 306 mm (II) VESA(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) VESA(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) VESA(0): Serial No: A17031600428 (II) VESA(0): Ranges: V min: 50 V max: 85 Hz, H min: 30 H max: 82 kHz, PixClock max 180 kHz (II) VESA(0): Monitor name: VX2000 (==) VESA(0): DPI set to (75, 75) (**) VESA(0): Using "Shadow Framebuffer" (II) Loading sub module "shadow" (II) LoadModule: "shadow" (II) Loading /usr/X11R6/lib/modules/libshadow.a (II) Module shadow: vendor="The XFree86 Project" compiled for 4.0.3, module version = 1.0.0 ABI class: XFree86 ANSI C Emulation, version 0.1 (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/X11R6/lib/modules/libfb.a (II) Module fb: vendor="The XFree86 Project" compiled for 4.0.3, module version = 1.0.0 ABI class: XFree86 ANSI C Emulation, version 0.1 Symbol cfb24_32ScreenInit from module /usr/X11R6/lib/modules/drivers/vesa_drv.o is unresolved! Symbol cfb24_32ScreenInit from module /usr/X11R6/lib/modules/drivers/vesa_drv.o is unresolved!

.... и т.д. В общем ничего не запустилось

------------------------------------------------------------ Может кто подскажет, в чем дело. Может можно установить более новую версию X11R6? Но у меня есть ограничение - версия ядра должна быть 2.4.9-13, так что совсем новую установить не получится :-(

В модульном драйвере под ядро 2.4 в точке входа write () есть такой код:

init_waitqueue_entry(&wait,current);

add_wait_queue(&devData->wait_queue, &wait);

// Инициализирую и запускаю таймер

devData->timer.expires = jiffies + HZ*((float)devData->timeout / 1000.);

add_timer(&devData->timer);

// программирую железяку для выдачи прерываний

mppa_start_irq(devData);

// жду либо прерываний, либо таймаута

interruptible_sleep_on(&devData->wait_queue);

remove_wait_queue(&devData->wait_queue, &wait);

Так вот, если потом wake_up_interruptible(&devData->wait_queue) вызывается из обработчика таймера - все нормально, write() разблокируется, а если прерывания все-таки были и wake_up_interruptible(&devData->wait_queue) вызывается из соответствующего тасклета - то write() чего-то не разблокируется. В чем может быть дело?

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

void my_hardware_service(){

disable_irq(irq);// дождется завершения обработчиков прерывания

// программирование железки

. . .

// готово

enable_irq(irq); }

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

Речь идет об обработке системных вызовов ioctl() в модульном драйвере.

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