/dev에서 누락된 장치 파일을 수정하는 올바른 방법은 무엇입니까?

/dev에서 누락된 장치 파일을 수정하는 올바른 방법은 무엇입니까?

저는 Ubunut 14.04 시스템에서 Sensoray의 독점 PCI 카드를 사용하고 있습니다(곧 18.04로 업그레이드할 계획입니다). 카드에는 드라이버의 소스 코드와 드라이버 구축 및 설치를 위한 Makefile이 함께 제공됩니다. Makefile의 드라이버 관련 부분은 다음 위치에 있습니다.

######################################################################
# for kernel modeule level driver:

# Kernel directory
KDIR        := /lib/modules/$(shell uname -r)/build
# Module directory
MODDIR      := /lib/modules/$(shell uname -r)/kernel/drivers/sensoray

# System values
PWD     := $(shell pwd)
KERNEL_24   := $(if $(wildcard $(KDIR)/Rules.make),1,0)

# Target file
obj-m       := s626.o


# Source files
ifeq    ($(KERNEL_24),0) # > 2.4
s626-objs   := s626drv.o 
else # <= 2.4
s626-objs   := s626drv.o
endif

.PHONY:     all clean modules_install

ifeq    ($(KERNEL_24),0) # > 2.4
ifeq    ($(KERNELRELEASE),)
all:
        $(MAKE) -C $(KDIR) M=$(PWD) SUBDIRS=$(PWD)
clean modules_install:
        $(MAKE) -C $(KDIR) M=$(PWD) SUBDIRS=$(PWD) $@
endif   # KERNELRELEASE

else    # <= 2.4

ifneq   ($(KERNELRELEASE),)

include $(KDIR)/Rules.make

s626.o: $(s626-objs)
        $(Q)$(LD) $(LD_RFLAG) -r -o $@ $(s626-objs)
else

all:
        $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
clean:
        rm -f *.ko *.o .*.cmd .*.o.flags *.mod.c

endif   # KERNELRELEASE

endif   # KERNEL_24

ifeq    ($(KERNEL_24),1) # <= 2.4

install:        s626.o
    @if [ -d /lib/modules/$(shell uname -r)/kernel/drivers/sensoray/ ];\
    then rm -f /lib/modules/$(shell uname -r)/kernel/drivers/sensoray/s626.*;\
    fi
    @if [ -d /lib/modules/$(shell uname -r)/extra/ ];\
    then rm -f /lib/modules/$(shell uname -r)/extra/s626.*;\
    fi
    su -c "set -x;./MAKEDEV;mkdir -p $(MODDIR);cp -v s626.o $(MODDIR);depmod -a"

else
install:        s626.ko
    @if [ -d /lib/modules/$(shell uname -r)/kernel/drivers/sensoray/ ];\
    then rm -f /lib/modules/$(shell uname -r)/kernel/drivers/sensoray/s626.*; \
    fi
    @if [ -d /lib/modules/$(shell uname -r)/extra/ ];\
    then rm -f /lib/modules/$(shell uname -r)/extra/s626.*;\
    fi
    @if [ -d /lib/modules/$(shell uname -r)/kernel/drivers/staging/comedi/drivers ];\
    then rm -f /lib/modules/$(shell uname -r)/kernel/drivers/staging/comedi/drivers/s626.*;\
    fi
    su -c "set -x;./MAKEDEV;mkdir -p $(MODDIR);cp -v s626.ko $(MODDIR);install -m 444 s626.ko $(MODDIR);depmod -a"
endif  # KERNEL > 2.4

Makefile의 끝 부분에서는 파일이 생성된 후 디렉터리 .ko에 간단히 복사되는 것처럼 보입니다 . /lib/modules/$(shell uname -r)/kernel/drivers/sensoray장치 파일을 생성하기 위해 실행되는 사용자 정의 MAKEDEV 쉘 스크립트도 있습니다. 스크립트는 다음과 같습니다.

#!/bin/bash

function makedev () {

    for dev in 0 1 2 3; do
        echo "/dev/$1$dev: char $2 $dev"
        rm -f /dev/$1$dev
        mknod /dev/$1$dev c $2 $dev
        chmod 666 /dev/$1$dev
    done

    # symlink for default device
    rm -f /dev/$1
    ln -s /dev/${1}0 /dev/$1
}

makedev s626a 146

문제는 시스템이 재부팅될 때마다 발생합니다. 드라이버가 올바르게 로드되는 것 같지만 장치 파일이 /dev사라졌습니다. 저는 드라이버 개발에 대해 잘 모르지만 이 문제에 대해 많은 연구를 했으며 부팅 시 이러한 장치 파일을 생성하는 방법에 대해 상충되는 정보를 발견했습니다. 어떤 사람들은 udev 규칙을 만드는 것이 가장 좋다고 말하고, 어떤 사람들은 udev 규칙을 사용하여 누락된 장치 파일을 생성해서는 안 된다거나 udev가 더 이상 새로운 devtempfs를 참조하는 장치 파일 생성에 책임을 지지 않는다고 말합니다. 내 질문은: 이 문제를 해결하는 올바른 방법은 무엇입니까? 나는 본질적으로 Sensoray에서 사용자 정의 MAKEDEV 스크립트를 호출하는 udev 규칙 접근 방식을 시도했지만 이는 내 규칙이 pci 카드의 특정 속성을 참조하지 않는 경우에만 작동합니다. 예를 들어 다음 규칙이 유효합니다.

ACTION=="add", SUBSYSTEM=="pci", RUN+="/home/kpopek/MAKEDEV"

이 규칙은 그렇지 않습니다.

ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x1131", RUN+="/home/kpopek/MAKEDEV"

부팅 시 ueventSensoray PCI 카드와 일치하는 항목이 없는 것 같습니다. 이는 누락된 장치 파일의 소스일 수 있습니다. uevents이것을 확인하기 위해 시작에 로그온하는 방법을 찾지 못했습니다 . udev 규칙이 올바른 접근 방식이라면 uevent다른 장치에서 발생하기 때문에 스크립트를 실행하는 일반적인 규칙 보다는 카드별 규칙을 정말 좋아합니다 .

답변1

사용자 정의 드라이버가 필수 udev 이벤트를 생성하지 않는 것 같습니다(이를 확인하려면 드라이버를 살펴봐야 합니다).

그래서적절한해결책은 이벤트를 생성하도록 드라이버를 수정하는 것입니다. 가장 간단한 경우 코드는 다음과 같습니다.이것. 더 복잡한 경우에는 추가 udev 규칙을 사용하여 더 복잡한 작업을 수행할 수 있습니다.

커널 모듈을 수정할 수 없거나 수정하고 싶지 않은 경우 가능한 모든 솔루션이 허용됩니다. IMHO. 이상적으로는 모듈이 로드될 때 장치를 생성하고 모듈이 언로드될 때 장치를 제거하는 종속성을 갖고 싶지만 udev 이벤트가 필요합니다(위 참조). 따라서 차선책은 부팅 시 생성하는 것입니다. 즉, init.d 또는 systemd 스크립트만 추가하면 됩니다.

하드웨어의 기존 udev 이벤트를 하이재킹할 수 있다면 그것도 좋을 것입니다. 하지만 시도했지만 찾지 못한 것 같습니다.

관련 정보