Linux – Linux上のデバイスに関連付けられているドライバー（モジュール）を見つける方法は？

Linuxの場合、次のようになります。
デバイス、たとえば / dev / sda 、
およびそのメジャー番号とマイナー番号（例： 8、0 ）、
どのモジュール/ドライバーがそれを「駆動」しているのかをどうやって知ることができますか？
/ sys を掘り下げることはできますか？または/proc それを発見するには？
承認された回答：

sysfsからこの情報を取得するにはデバイスファイルの場合、最初に ls -l </ code>の出力を見て、メジャー/マイナー番号を決定します。、例
  $ ls -l /dev/sda
 brw-rw---- 1 root disk 8, 0 Apr 17 12:26 /dev/sda
 
  8、0  メジャー番号は8であることがわかります マイナーはです 。  b  リストの冒頭にあるのは、それがブロックデバイスであることも示しています。他のデバイスにはcがある場合があります 開始時のキャラクターデバイス用。
 
 次に、 / sys / devの下を見てください。 、2つのディレクトリがあることがわかります。  blockと呼ばれるもの  charと呼ばれるもの 。ここで簡単なのは、これらがそれぞれブロックデバイスとキャラクターデバイス用であるということです。各デバイスには、このディレクトリのメジャー/マイナー番号でアクセスできます。デバイスで使用可能なドライバーがある場合は、 driverのターゲットを読み取ることで見つけることができます。 このリンクまたはデバイス サブディレクトリ。例：私の / dev / sda  簡単にできること：
 $ readlink /sys/dev/block/8\:0/device/driver
../../../../../../../bus/scsi/drivers/sd
 
 これは、 sdが デバイスにはドライバーが使用されます。デバイスがブロックデバイスなのかキャラクターデバイスなのかわからない場合は、シェルでこの部分を *に置き換えるだけです。 。これも同様に機能します：
 $ readlink /sys/dev/*/8\:0/device/driver
../../../../../../../bus/scsi/drivers/sd
 
 ブロックデバイスには、 / sys / blockのいずれかを介して名前から直接アクセスすることもできます。 または/sys / class / block  。例：
 $ readlink /sys/block/sda/device/driver
../../../../../../../bus/scsi/drivers/sd
 
  / sysにはさまざまなディレクトリが存在することに注意してください カーネル構成によって変わる場合があります。また、すべてのデバイスに deviceがあるわけではありません サブフォルダー。たとえば、これは / dev / sda1のようなパーティションデバイスファイルの場合です。 。ここでは、ディスク全体のデバイスにアクセスする必要があります（残念ながら、 sysはありません。 このためのリンク）。
 
 最後に役立つのは、使用可能なすべてのデバイスのドライバーを一覧表示することです。このために、グロブを使用して、ドライバーリンクが存在するすべてのディレクトリを選択できます。例：
 $ ls -l /sys/dev/*/*/device/driver && ls -l /sys/dev/*/*/driver 
lrwxrwxrwx 1 root root 0 Apr 17 12:27 /sys/dev/block/11:0/device/driver -> ../../../../../../../bus/scsi/drivers/sr
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/block/8:0/device/driver -> ../../../../../../../bus/scsi/drivers/sd
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/block/8:16/device/driver -> ../../../../../../../bus/scsi/drivers/sd
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/block/8:32/device/driver -> ../../../../../../../../../bus/scsi/drivers/sd
lrwxrwxrwx 1 root root 0 Apr 17 20:38 /sys/dev/char/189:0/driver -> ../../../../bus/usb/drivers/usb
lrwxrwxrwx 1 root root 0 Apr 17 20:38 /sys/dev/char/189:1024/driver -> ../../../../bus/usb/drivers/usb
lrwxrwxrwx 1 root root 0 Apr 17 20:38 /sys/dev/char/189:128/driver -> ../../../../bus/usb/drivers/usb
lrwxrwxrwx 1 root root 0 Apr 17 20:38 /sys/dev/char/189:256/driver -> ../../../../bus/usb/drivers/usb
lrwxrwxrwx 1 root root 0 Apr 17 20:38 /sys/dev/char/189:384/driver -> ../../../../bus/usb/drivers/usb
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/189:512/driver -> ../../../../bus/usb/drivers/usb
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/189:513/driver -> ../../../../../bus/usb/drivers/usb
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/189:514/driver -> ../../../../../bus/usb/drivers/usb
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/189:640/driver -> ../../../../bus/usb/drivers/usb
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/189:643/driver -> ../../../../../bus/usb/drivers/usb
lrwxrwxrwx 1 root root 0 Apr 17 20:38 /sys/dev/char/189:768/driver -> ../../../../bus/usb/drivers/usb
lrwxrwxrwx 1 root root 0 Apr 17 20:38 /sys/dev/char/189:896/driver -> ../../../../bus/usb/drivers/usb
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/21:0/device/driver -> ../../../../../../../bus/scsi/drivers/sd
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/21:1/device/driver -> ../../../../../../../bus/scsi/drivers/sd
lrwxrwxrwx 1 root root 0 Apr 17 12:27 /sys/dev/char/21:2/device/driver -> ../../../../../../../bus/scsi/drivers/sr
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/21:3/device/driver -> ../../../../../../../../../bus/scsi/drivers/sd
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/250:0/device/driver -> ../../../../../../../bus/hid/drivers/hid-generic
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/250:1/device/driver -> ../../../../../../../bus/hid/drivers/hid-generic
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/250:2/device/driver -> ../../../../../../../bus/hid/drivers/hid-generic
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/252:0/device/driver -> ../../../../../../../bus/scsi/drivers/sd
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/252:1/device/driver -> ../../../../../../../bus/scsi/drivers/sd
lrwxrwxrwx 1 root root 0 Apr 17 12:27 /sys/dev/char/252:2/device/driver -> ../../../../../../../bus/scsi/drivers/sr
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/252:3/device/driver -> ../../../../../../../../../bus/scsi/drivers/sd
lrwxrwxrwx 1 root root 0 Apr 17 19:53 /sys/dev/char/254:0/device/driver -> ../../../bus/pnp/drivers/rtc_cmos
lrwxrwxrwx 1 root root 0 Apr 17 19:53 /sys/dev/char/29:0/device/driver -> ../../../bus/platform/drivers/simple-framebuffer
lrwxrwxrwx 1 root root 0 Apr 17 19:53 /sys/dev/char/4:64/device/driver -> ../../../bus/pnp/drivers/serial
lrwxrwxrwx 1 root root 0 Apr 17 19:53 /sys/dev/char/4:65/device/driver -> ../../../bus/platform/drivers/serial8250
lrwxrwxrwx 1 root root 0 Apr 17 19:53 /sys/dev/char/4:66/device/driver -> ../../../bus/platform/drivers/serial8250
lrwxrwxrwx 1 root root 0 Apr 17 19:53 /sys/dev/char/4:67/device/driver -> ../../../bus/platform/drivers/serial8250
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/6:0/device/driver -> ../../../bus/pnp/drivers/parport_pc
lrwxrwxrwx 1 root root 0 Apr 17 12:26 /sys/dev/char/99:0/device/driver -> ../../../bus/pnp/drivers/parport_pc
 
 最後に、質問から少し逸脱するために、別の / sysを追加します。 どのドライバーがどのデバイスで使用されているか（必ずしもデバイスファイルを使用しているとは限りません）について、より広い視点を取得するためのglobトリック：
 find /sys/bus/*/drivers/* -maxdepth 1 -lname '*devices*' -ls
 更新
 
  udevadmの出力を詳しく見てみましょう 、正規の / sysを見つけることで機能するようです ディレクトリ（上記のメジャー/マイナーディレクトリを逆参照した場合に得られるように）、ディレクトリツリーを上に向かって進み、見つかった情報を出力します。このようにして、親デバイスとそれらが使用するドライバーに関する情報を取得します。
 関連：Linux – watchコマンドを使用した後、特定のプログラムの出力の監視を停止しますか？ 
 これを試すために、以下のスクリプトを作成して、ディレクトリツリーをたどり、関連する各レベルの情報を表示しました。  udev  名前と内容がATTRSに組み込まれている、各レベルで読み取り可能なファイルを探しているようです。 。これを行う代わりに、 ueventの内容を表示します 各レベルのファイル（これが存在すると、単なるサブディレクトリではなく、個別のレベルが定義されるようです）。また、見つけたサブシステムリンクのベース名と、デバイスがこの階層にどのように適合するかを示します。  udevadm  同じ情報を表示しないので、これは優れた補完ツールです。親デバイス情報（例： PCI  information）は、 lshwなどの他のツールの出力と一致させる場合にも役立ちます。 より高いレベルのデバイスに。
 #!/bin/bash

dev=$(readlink -m $1)

# test for block/character device
if [ -b "$dev" ]; then
  mode=block
elif [ -c "$dev" ]; then
  mode=char
else
  echo "$dev is not a device file" >&2
  exit 1
fi

# stat outputs major/minor in hex, convert to decimal
data=( $(stat -c '%t %T' $dev) ) || exit 2
major=$(( 0x${data[0]} ))
minor=$(( 0x${data[1]} ))

echo -e "Given device:     $1"
echo -e "Canonical device: $dev"
echo -e "Major: $major"
echo -e "Minor: $minor\n"

# sometimes nodes have been created for devices that are not present
dir=$(readlink -f /sys/dev/$mode/$major\:$minor)
if ! [ -e "$dir" ]; then
  echo "No /sys entry for $dev" >&2
  exit 3
fi

# walk up the /sys hierarchy one directory at a time
# stop when there are three levels left 
while [[ $dir == /*/*/* ]]; do

  # it seems the directory is only of interest if there is a 'uevent' file
  if [ -e "$dir/uevent" ]; then
    echo "$dir:"
    echo "  Uevent:"
    sed 's/^/    /' "$dir/uevent"

    # check for subsystem link
    if [ -d "$dir/subsystem" ]; then
        subsystem=$(readlink -f "$dir/subsystem")
        echo -e "\n  Subsystem:\n    ${subsystem##*/}"
    fi

    echo
  fi

  # strip a subdirectory
  dir=${dir%/*}
done