How to find the driver (module) associated with a device on Linux?
how can I know which module / driver is «driving» it?
Can I dig into /sys or /proc to discover that?
Totor, I added the bounty because another user posted the same question because he felt that this one had not received enough attention. I asked him to delete his question and offered a bounty on this one to get more answers. Please remember to accept one of the answers below if they answer your question.
@terdon thanks for the bounty, it produced nice answers. I have not carefully tested everything yet, but will accept Graeme‘s answer in the meanwhile.
4 Answers 4
To get this information from sysfs for a device file, first determine the major/minor number by looking at the output of ls -l , eg
$ ls -l /dev/sda brw-rw---- 1 root disk 8, 0 Apr 17 12:26 /dev/sda The 8, 0 tells us that major number is 8 and the minor is 0 . The b at the start of the listing also tells us that it is a block device. Other devices may have a c for character device at the start.
If you then look under /sys/dev , you will see there are two directories. One called block and one called char . The no-brainer here is that these are for block and character devices respectively. Each device is then accessible by its major/minor number is this directory. If there is a driver available for the device, it can be found by reading the target of the driver link in this or the device sub-directory. Eg, for my /dev/sda I can simply do:
$ readlink /sys/dev/block/8\:0/device/driver ../../../../../../../bus/scsi/drivers/sd This shows that the sd driver is used for the device. If you are unsure if the device is a block or character device, in the shell you could simply replace this part with a * . This works just as well:
$ readlink /sys/dev/*/8\:0/device/driver ../../../../../../../bus/scsi/drivers/sd Block devices can also be accessed directly through their name via either /sys/block or /sys/class/block . Eg:
$ readlink /sys/block/sda/device/driver ../../../../../../../bus/scsi/drivers/sd Note that the existence of various directories in /sys may change depending on the kernel configuration. Also not all devices have a device subfolder. For example, this is the case for partition device files like /dev/sda1 . Here you have to access the device for the whole disk (unfortunately there are no sys links for this).
A final thing which can be useful to do is to list the drivers for all devices for which they are available. For this you can use globs to select all the directories in which the driver links are present. Eg:
$ 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 Finally, to diverge from the question a bit, I will add another /sys glob trick to get a much broader perspective on which drivers are being used by which devices (though not necessarily those with a device file):
find /sys/bus/*/drivers/* -maxdepth 1 -lname '*devices*' -ls Update
Looking more closely at the output of udevadm , it appears to work by finding the canonical /sys directory (as you would get if you dereferenced the major/minor directories above), then working its way up the directory tree, printing out any information that it finds. This way you get information about parent devices and any drivers they use as well.
To experiment with this I wrote the script below to walk up the directory tree and display information at each relevant level. udev seems to look for readable files at each level, with their names and contents being incorporated in ATTRS . Instead of doing this I display the contents of the uevent files at each level (seemingly the presence of this defines a distinct level rather than just a subdirectory). I also show the basename of any subsystem links I find and this showing how the device fits in this hierarchy. udevadm does not display the same information, so this is a nice complementary tool. The parent device information (eg PCI information) is also useful if you want to match the output of other tools like lshw to higher level devices.
#!/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$ )) minor=$(( 0x$ )) 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 $" fi echo fi # strip a subdirectory dir=$ done Where to find a list of device drivers supported by linux?
I have read here that linux supports a large number of device drivers and by extension, it also supports a large number of devices connected via the USB port. Excerpt from that site:
Linux today supports more hardware devices than any other operating system in the history of the world. It does this using a development model significantly different from the familiar Windows device driver model.
Is there a list of all the different devices which are supported by linux ? and/or list of devices which are connected via USB and supported by linux`? This is different from just finding out which device drivers are currently supported in a given distribution by using the commands lsmod , lspci and dmesg | grep
@MarkPlotnick, that is not what I meant. I meant, if a certain device is not supported by the kernel, should I then look for driver modules from the manufacturer of the device, or should I consider writing my own device driver? So, if there was a list, then it would help a developer know whether he has to write his own driver or if the kernel itself provided it
3 Answers 3
The lspci and lsusb commands just enumerates the devices connected to particular buses. They read id from the bus and use special file to map this ids to strings.
The lsmod showns just list of linux kernel modules. Linux kernel module is part of linux kernel code which is loaded dynamically — this modules are not necessary drivers, it may be just any part of the kernel code. This mechanism is used to save memory and boot time and do not load all code on boot, to make kernel development easier (you can unload/modify/load parts of the kernel). As the device driver is one of good applications of this dynamic loading — it is used in most drivers. The non-driver example is iptables (the network filtering mechanism) there only parts are loaded which are actually requested by user.
The dmesg is just a kernel text log — usually developer white something there in case of initialization, but this is entirely voluntary — so what you find there and which format is completely random.
Complete lists of the supported hardware is hard thing to get. Kernel consists of very different parts made by different people and there is a lot of similar devices with different labels.
Usually you can try to find if your device is supported on dedicated pages:
- supported printers are on the linux printer database http://www.openprinting.org/printers
- scanners are are sane page
- video card on http://www.x.org/wiki/Projects/Drivers/
- and so on
This is mainly because most things require not just kernel driver by also kind of userspace layer and there is kind of ‘project’ which does both parts with main interface in userspace.
Most advanced list of the supported may be extracted from kernel code — there is usually list of pci/usb ids supported for each particular drivers — there is a way to extract it: http://www.cyberciti.biz/tips/linux-find-supported-pci-hardware-drivers.html. But if you have kernel module which has an ID in the list doesn’t mean that device is fully supported or that you have userspace tools which allow you to use this module, or that this userspace tools exist in your particular distribution.
Sometimes distribution vendors provide list of supported devices, but this is usually some small subset.
For debian there is also list of pciid->kernel module mappings: https://wiki.debian.org/DeviceDatabase/PCI.
Regarding usb devices, many things like cameras have kind of userspace drivers via libusb — like cameras or so no. In such case you have no need in kernel driver at all.
Also, don’t forget that linux runs on near 20 architectures (imagine how many drivers are in billions of different android smart-phones), each with own huge set of drivers — and you’ll see that total amount will easily beat every other knows OS.