修復 /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 shell 腳本正在執行以創建設備文件。該腳本在這裡給出:#!/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。我的問題是:解決此問題的正確方法是什麼?我已經嘗試過 udev 規則方法,在該方法中我基本上從 Sensoray 呼叫自定義 MAKEDEV 腳本,但這僅在我的規則不引用 pci 卡的任何特定屬性時才有效。例如,以下規則有效:ACTION=="add", SUBSYSTEM=="pci", RUN+="/home/kpopek/MAKEDEV"
該規則不
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x1131", RUN+="/home/kpopek/MAKEDEV"
在啟動時似乎沒有任何
uevent
與 Sensoray pci 卡匹配的東西,這可能是缺少設備文件的根本原因。我還沒有弄清楚如何uevents
在啟動時記錄以驗證這一點。如果 udev 規則是正確的方法,我真的想要一個特定於卡的規則,而不是由於uevent
來自另一台設備而碰巧執行腳本的通用規則。
看起來自定義驅動程序沒有生成所需的 udev 事件(必須查看驅動程序來確認這一點)。
因此,正確的方法是修復驅動程序以生成事件。在最簡單的情況下,您將擁有類似於this的程式碼。在更複雜的情況下,您可以擁有額外的 udev 規則來完成更複雜的事情。
如果您不能或不想修改核心模組,恕我直言,任何可行的解決方案都是允許的。理想情況下,您希望有一個依賴項,該依賴項在載入模組時創建設備,並在解除安裝時刪除它,但您需要 udev 事件(見上文)。所以下一個最好的事情是在啟動時創建它,這意味著我只需添加一個 init.d 或 systemd 腳本。
如果您可以為您的硬體劫持現有的 udev 事件,那也很好,但看起來您已經嘗試過但沒有找到。