How does Linux know how and what drivers to install in a new installation












2















I would like to know how Linux, such us Ubuntu, "know" how and what drivers to install when installing it from scratch.
For example, I buy a new computer without any system and I install Ubuntu. Inside my PC I have a GPU, HDDs, etc., also some peripherals, like mouse, keyboard, etc. Obviously, a fresh install does not have drivers needed for the system to control and communicate with the hardware so how does Ubuntu "know" what drivers to install/download and how does it do that?










share|improve this question




















  • 2





    It doesn't know this during installation, it simply install all the files. And your "obviously" is wrong, as long as OS is running, it uses drivers to operate on hardware

    – 炸鱼薯条德里克
    Feb 10 at 1:42











  • So how does it "know" to operate my graphics card, for example? Every PC or laptop has different graphics card, how does it "know" to operate it?

    – jedi
    Feb 10 at 1:55











  • There's a different between using a software and having a software installed. The kernel know which driver to use.

    – 炸鱼薯条德里克
    Feb 10 at 3:26
















2















I would like to know how Linux, such us Ubuntu, "know" how and what drivers to install when installing it from scratch.
For example, I buy a new computer without any system and I install Ubuntu. Inside my PC I have a GPU, HDDs, etc., also some peripherals, like mouse, keyboard, etc. Obviously, a fresh install does not have drivers needed for the system to control and communicate with the hardware so how does Ubuntu "know" what drivers to install/download and how does it do that?










share|improve this question




















  • 2





    It doesn't know this during installation, it simply install all the files. And your "obviously" is wrong, as long as OS is running, it uses drivers to operate on hardware

    – 炸鱼薯条德里克
    Feb 10 at 1:42











  • So how does it "know" to operate my graphics card, for example? Every PC or laptop has different graphics card, how does it "know" to operate it?

    – jedi
    Feb 10 at 1:55











  • There's a different between using a software and having a software installed. The kernel know which driver to use.

    – 炸鱼薯条德里克
    Feb 10 at 3:26














2












2








2


1






I would like to know how Linux, such us Ubuntu, "know" how and what drivers to install when installing it from scratch.
For example, I buy a new computer without any system and I install Ubuntu. Inside my PC I have a GPU, HDDs, etc., also some peripherals, like mouse, keyboard, etc. Obviously, a fresh install does not have drivers needed for the system to control and communicate with the hardware so how does Ubuntu "know" what drivers to install/download and how does it do that?










share|improve this question
















I would like to know how Linux, such us Ubuntu, "know" how and what drivers to install when installing it from scratch.
For example, I buy a new computer without any system and I install Ubuntu. Inside my PC I have a GPU, HDDs, etc., also some peripherals, like mouse, keyboard, etc. Obviously, a fresh install does not have drivers needed for the system to control and communicate with the hardware so how does Ubuntu "know" what drivers to install/download and how does it do that?







linux ubuntu






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 10 at 3:19









Rui F Ribeiro

40.4k1479137




40.4k1479137










asked Feb 10 at 1:00









jedijedi

1386




1386








  • 2





    It doesn't know this during installation, it simply install all the files. And your "obviously" is wrong, as long as OS is running, it uses drivers to operate on hardware

    – 炸鱼薯条德里克
    Feb 10 at 1:42











  • So how does it "know" to operate my graphics card, for example? Every PC or laptop has different graphics card, how does it "know" to operate it?

    – jedi
    Feb 10 at 1:55











  • There's a different between using a software and having a software installed. The kernel know which driver to use.

    – 炸鱼薯条德里克
    Feb 10 at 3:26














  • 2





    It doesn't know this during installation, it simply install all the files. And your "obviously" is wrong, as long as OS is running, it uses drivers to operate on hardware

    – 炸鱼薯条德里克
    Feb 10 at 1:42











  • So how does it "know" to operate my graphics card, for example? Every PC or laptop has different graphics card, how does it "know" to operate it?

    – jedi
    Feb 10 at 1:55











  • There's a different between using a software and having a software installed. The kernel know which driver to use.

    – 炸鱼薯条德里克
    Feb 10 at 3:26








2




2





It doesn't know this during installation, it simply install all the files. And your "obviously" is wrong, as long as OS is running, it uses drivers to operate on hardware

– 炸鱼薯条德里克
Feb 10 at 1:42





It doesn't know this during installation, it simply install all the files. And your "obviously" is wrong, as long as OS is running, it uses drivers to operate on hardware

– 炸鱼薯条德里克
Feb 10 at 1:42













So how does it "know" to operate my graphics card, for example? Every PC or laptop has different graphics card, how does it "know" to operate it?

– jedi
Feb 10 at 1:55





So how does it "know" to operate my graphics card, for example? Every PC or laptop has different graphics card, how does it "know" to operate it?

– jedi
Feb 10 at 1:55













There's a different between using a software and having a software installed. The kernel know which driver to use.

– 炸鱼薯条德里克
Feb 10 at 3:26





There's a different between using a software and having a software installed. The kernel know which driver to use.

– 炸鱼薯条德里克
Feb 10 at 3:26










2 Answers
2






active

oldest

votes


















3














All peripherals identify themselves with mostly unique IDs. Some IDs are for generic interfaces (HDD/mouse,etc). Linux has most drivers built in, and the generic drivers have compatibility lists for IDs that support a limited feature set.It gets more complicated but dmesg, lscpu, hwinfo, lshw, dmidecode, lspci, etc will list the IDs if you want to look






share|improve this answer

































    1














    (Based on Google-cached copy of http://people.skolelinux.org/pere/blog/Modalias_strings___a_practical_way_to_map__stuff__to_hardware.html by Petter Reinholdtsen.)



    In the hardware, there are certain standard device identifiers that can be accessed as long as you know the standard access method for that particular I/O bus or subsystem, without having any further knowledge about the actual device. In Linux, these identifiers are used to build up modalias strings, which are then used to find the correct driver for each device.



    The source code of each driver module can include MODULE_DEVICE_TABLE structures, which are used by the depmod command to create module alias wildcard entries that will match the modalias strings of the hardware supported by that particular module.



    When the kernel detects a piece of hardware with no matching driver loaded yet, it will create a modalias string from the identifiers of the hardware, and use it to request a module to be autoloaded. The modprobe command will then use the /lib/modules/$(uname -r)/modules.alias[.bin] file created by depmod to see if a matching module exists. If it does, that module is loaded and gets to probe the hardware for further details if necessary.



    For example, I have a DVB TV card:



    $ lspci -v -nn -s 07:00.0
    07:00.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 04)
    Subsystem: Hauppauge computer works Inc. CX23885 PCI Video and Audio Decoder [0070:6a28]


    This results in a modalias string like this:



    pci:v000014F1d00008852sv00000070sd00006A28bc04sc00i00


    The cx23885 module has these aliases based on MODULE_DEVICE_TABLE in its source code:



    # modinfo cx23885
    ...
    alias: pci:v000014F1d00008880sv*sd*bc*sc*i*
    alias: pci:v000014F1d00008852sv*sd*bc*sc*i*
    ...


    When the kernel detects the card, it effectively runs the modprobe pci:v000014F1d00008852sv00000070sd00006A28bc04sc00i00 command. The second alias of the cx23885 module matches, and so that module gets loaded.



    PCI/PCI-X/PCIe bus devices



    This is the "PCI subtype". It uses modalias strings like this:



    pci:v00008086d00002770sv00001028sd000001ADbc06sc00i00


    This can be decoded as follows:



    v   00008086  (vendor)
    d 00002770 (device)
    sv 00001028 (subvendor)
    sd 000001AD (subdevice)
    bc 06 (bus class)
    sc 00 (bus subclass)
    i 00 (interface)


    With lspci -nn, you can see the class, subclass, vendor and device IDs. If you add the -v option, you can also see the subvendor:subdevice IDs.



    USB devices



    With USB devices, the modalias strings look like this:



    usb:v1D6Bp0001d0206dc09dsc00dp00ic09isc00ip00


    This unpacks to:



    v    1D6B  (device vendor)
    p 0001 (device product)
    d 0206 (bcddevice)
    dc 09 (device class)
    dsc 00 (device subclass)
    dp 00 (device protocol)
    ic 09 (interface class)
    isc 00 (interface subclass)
    ip 00 (interface protocol)


    With the lsusb command, you can see the vendor and product IDs. If you use the -v option, you can see the other IDs too.



    ACPI devices



    These use the ACPI PNP identifiers, prefixed with acpi: and separated with colons:



    acpi:IBM0071:PNP0511:


    DMI devices



    This can be a very long modalias string:



    dmi:bvnIBM:bvr1UETB6WW(1.66):bd06/15/2005:svnIBM:pn2371H4G:pvrThinkPadX40:rvnIBM:rn2371H4G:rvrNotAvailable:cvnIBM:ct10:cvrNotAvailable:


    This unpacks to:



    bvn  IBM            (BIOS vendor)
    bvr 1UETB6WW(1.66) (BIOS version)
    bd 06/15/2005 (BIOS date)
    svn IBM (system vendor)
    pn 2371H4G (product name)
    pvr ThinkPadX40 (product version)
    rvn IBM (board vendor)
    rn 2371H4G (board name)
    rvr NotAvailable (board version)
    cvn IBM (chassis vendor)
    ct 10 (chassis type)
    cvr NotAvailable (chassis version)


    SerIO devices, i.e. mostly PS/2 mice



    The modalias string will look like this:



    serio:ty01pr00id00ex00


    The values here are:



    ty  01  (type)
    pr 00 (prototype)
    id 00 (id)
    ex 00 (extra)


    Other bus/device types



    There are many other bus types recognized by the Linux kernel. Studying the contents of the kernel source file file2alias.c might be helpful in deciphering the meaning of the components of each type of modalias string.






    share|improve this answer
























    • This is a very good answer, very extensive and very informative. Thank you.

      – jedi
      Feb 11 at 13:36











    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499716%2fhow-does-linux-know-how-and-what-drivers-to-install-in-a-new-installation%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    3














    All peripherals identify themselves with mostly unique IDs. Some IDs are for generic interfaces (HDD/mouse,etc). Linux has most drivers built in, and the generic drivers have compatibility lists for IDs that support a limited feature set.It gets more complicated but dmesg, lscpu, hwinfo, lshw, dmidecode, lspci, etc will list the IDs if you want to look






    share|improve this answer






























      3














      All peripherals identify themselves with mostly unique IDs. Some IDs are for generic interfaces (HDD/mouse,etc). Linux has most drivers built in, and the generic drivers have compatibility lists for IDs that support a limited feature set.It gets more complicated but dmesg, lscpu, hwinfo, lshw, dmidecode, lspci, etc will list the IDs if you want to look






      share|improve this answer




























        3












        3








        3







        All peripherals identify themselves with mostly unique IDs. Some IDs are for generic interfaces (HDD/mouse,etc). Linux has most drivers built in, and the generic drivers have compatibility lists for IDs that support a limited feature set.It gets more complicated but dmesg, lscpu, hwinfo, lshw, dmidecode, lspci, etc will list the IDs if you want to look






        share|improve this answer















        All peripherals identify themselves with mostly unique IDs. Some IDs are for generic interfaces (HDD/mouse,etc). Linux has most drivers built in, and the generic drivers have compatibility lists for IDs that support a limited feature set.It gets more complicated but dmesg, lscpu, hwinfo, lshw, dmidecode, lspci, etc will list the IDs if you want to look







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Feb 10 at 8:52









        Rui F Ribeiro

        40.4k1479137




        40.4k1479137










        answered Feb 10 at 5:46









        user1133275user1133275

        3,450723




        3,450723

























            1














            (Based on Google-cached copy of http://people.skolelinux.org/pere/blog/Modalias_strings___a_practical_way_to_map__stuff__to_hardware.html by Petter Reinholdtsen.)



            In the hardware, there are certain standard device identifiers that can be accessed as long as you know the standard access method for that particular I/O bus or subsystem, without having any further knowledge about the actual device. In Linux, these identifiers are used to build up modalias strings, which are then used to find the correct driver for each device.



            The source code of each driver module can include MODULE_DEVICE_TABLE structures, which are used by the depmod command to create module alias wildcard entries that will match the modalias strings of the hardware supported by that particular module.



            When the kernel detects a piece of hardware with no matching driver loaded yet, it will create a modalias string from the identifiers of the hardware, and use it to request a module to be autoloaded. The modprobe command will then use the /lib/modules/$(uname -r)/modules.alias[.bin] file created by depmod to see if a matching module exists. If it does, that module is loaded and gets to probe the hardware for further details if necessary.



            For example, I have a DVB TV card:



            $ lspci -v -nn -s 07:00.0
            07:00.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 04)
            Subsystem: Hauppauge computer works Inc. CX23885 PCI Video and Audio Decoder [0070:6a28]


            This results in a modalias string like this:



            pci:v000014F1d00008852sv00000070sd00006A28bc04sc00i00


            The cx23885 module has these aliases based on MODULE_DEVICE_TABLE in its source code:



            # modinfo cx23885
            ...
            alias: pci:v000014F1d00008880sv*sd*bc*sc*i*
            alias: pci:v000014F1d00008852sv*sd*bc*sc*i*
            ...


            When the kernel detects the card, it effectively runs the modprobe pci:v000014F1d00008852sv00000070sd00006A28bc04sc00i00 command. The second alias of the cx23885 module matches, and so that module gets loaded.



            PCI/PCI-X/PCIe bus devices



            This is the "PCI subtype". It uses modalias strings like this:



            pci:v00008086d00002770sv00001028sd000001ADbc06sc00i00


            This can be decoded as follows:



            v   00008086  (vendor)
            d 00002770 (device)
            sv 00001028 (subvendor)
            sd 000001AD (subdevice)
            bc 06 (bus class)
            sc 00 (bus subclass)
            i 00 (interface)


            With lspci -nn, you can see the class, subclass, vendor and device IDs. If you add the -v option, you can also see the subvendor:subdevice IDs.



            USB devices



            With USB devices, the modalias strings look like this:



            usb:v1D6Bp0001d0206dc09dsc00dp00ic09isc00ip00


            This unpacks to:



            v    1D6B  (device vendor)
            p 0001 (device product)
            d 0206 (bcddevice)
            dc 09 (device class)
            dsc 00 (device subclass)
            dp 00 (device protocol)
            ic 09 (interface class)
            isc 00 (interface subclass)
            ip 00 (interface protocol)


            With the lsusb command, you can see the vendor and product IDs. If you use the -v option, you can see the other IDs too.



            ACPI devices



            These use the ACPI PNP identifiers, prefixed with acpi: and separated with colons:



            acpi:IBM0071:PNP0511:


            DMI devices



            This can be a very long modalias string:



            dmi:bvnIBM:bvr1UETB6WW(1.66):bd06/15/2005:svnIBM:pn2371H4G:pvrThinkPadX40:rvnIBM:rn2371H4G:rvrNotAvailable:cvnIBM:ct10:cvrNotAvailable:


            This unpacks to:



            bvn  IBM            (BIOS vendor)
            bvr 1UETB6WW(1.66) (BIOS version)
            bd 06/15/2005 (BIOS date)
            svn IBM (system vendor)
            pn 2371H4G (product name)
            pvr ThinkPadX40 (product version)
            rvn IBM (board vendor)
            rn 2371H4G (board name)
            rvr NotAvailable (board version)
            cvn IBM (chassis vendor)
            ct 10 (chassis type)
            cvr NotAvailable (chassis version)


            SerIO devices, i.e. mostly PS/2 mice



            The modalias string will look like this:



            serio:ty01pr00id00ex00


            The values here are:



            ty  01  (type)
            pr 00 (prototype)
            id 00 (id)
            ex 00 (extra)


            Other bus/device types



            There are many other bus types recognized by the Linux kernel. Studying the contents of the kernel source file file2alias.c might be helpful in deciphering the meaning of the components of each type of modalias string.






            share|improve this answer
























            • This is a very good answer, very extensive and very informative. Thank you.

              – jedi
              Feb 11 at 13:36
















            1














            (Based on Google-cached copy of http://people.skolelinux.org/pere/blog/Modalias_strings___a_practical_way_to_map__stuff__to_hardware.html by Petter Reinholdtsen.)



            In the hardware, there are certain standard device identifiers that can be accessed as long as you know the standard access method for that particular I/O bus or subsystem, without having any further knowledge about the actual device. In Linux, these identifiers are used to build up modalias strings, which are then used to find the correct driver for each device.



            The source code of each driver module can include MODULE_DEVICE_TABLE structures, which are used by the depmod command to create module alias wildcard entries that will match the modalias strings of the hardware supported by that particular module.



            When the kernel detects a piece of hardware with no matching driver loaded yet, it will create a modalias string from the identifiers of the hardware, and use it to request a module to be autoloaded. The modprobe command will then use the /lib/modules/$(uname -r)/modules.alias[.bin] file created by depmod to see if a matching module exists. If it does, that module is loaded and gets to probe the hardware for further details if necessary.



            For example, I have a DVB TV card:



            $ lspci -v -nn -s 07:00.0
            07:00.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 04)
            Subsystem: Hauppauge computer works Inc. CX23885 PCI Video and Audio Decoder [0070:6a28]


            This results in a modalias string like this:



            pci:v000014F1d00008852sv00000070sd00006A28bc04sc00i00


            The cx23885 module has these aliases based on MODULE_DEVICE_TABLE in its source code:



            # modinfo cx23885
            ...
            alias: pci:v000014F1d00008880sv*sd*bc*sc*i*
            alias: pci:v000014F1d00008852sv*sd*bc*sc*i*
            ...


            When the kernel detects the card, it effectively runs the modprobe pci:v000014F1d00008852sv00000070sd00006A28bc04sc00i00 command. The second alias of the cx23885 module matches, and so that module gets loaded.



            PCI/PCI-X/PCIe bus devices



            This is the "PCI subtype". It uses modalias strings like this:



            pci:v00008086d00002770sv00001028sd000001ADbc06sc00i00


            This can be decoded as follows:



            v   00008086  (vendor)
            d 00002770 (device)
            sv 00001028 (subvendor)
            sd 000001AD (subdevice)
            bc 06 (bus class)
            sc 00 (bus subclass)
            i 00 (interface)


            With lspci -nn, you can see the class, subclass, vendor and device IDs. If you add the -v option, you can also see the subvendor:subdevice IDs.



            USB devices



            With USB devices, the modalias strings look like this:



            usb:v1D6Bp0001d0206dc09dsc00dp00ic09isc00ip00


            This unpacks to:



            v    1D6B  (device vendor)
            p 0001 (device product)
            d 0206 (bcddevice)
            dc 09 (device class)
            dsc 00 (device subclass)
            dp 00 (device protocol)
            ic 09 (interface class)
            isc 00 (interface subclass)
            ip 00 (interface protocol)


            With the lsusb command, you can see the vendor and product IDs. If you use the -v option, you can see the other IDs too.



            ACPI devices



            These use the ACPI PNP identifiers, prefixed with acpi: and separated with colons:



            acpi:IBM0071:PNP0511:


            DMI devices



            This can be a very long modalias string:



            dmi:bvnIBM:bvr1UETB6WW(1.66):bd06/15/2005:svnIBM:pn2371H4G:pvrThinkPadX40:rvnIBM:rn2371H4G:rvrNotAvailable:cvnIBM:ct10:cvrNotAvailable:


            This unpacks to:



            bvn  IBM            (BIOS vendor)
            bvr 1UETB6WW(1.66) (BIOS version)
            bd 06/15/2005 (BIOS date)
            svn IBM (system vendor)
            pn 2371H4G (product name)
            pvr ThinkPadX40 (product version)
            rvn IBM (board vendor)
            rn 2371H4G (board name)
            rvr NotAvailable (board version)
            cvn IBM (chassis vendor)
            ct 10 (chassis type)
            cvr NotAvailable (chassis version)


            SerIO devices, i.e. mostly PS/2 mice



            The modalias string will look like this:



            serio:ty01pr00id00ex00


            The values here are:



            ty  01  (type)
            pr 00 (prototype)
            id 00 (id)
            ex 00 (extra)


            Other bus/device types



            There are many other bus types recognized by the Linux kernel. Studying the contents of the kernel source file file2alias.c might be helpful in deciphering the meaning of the components of each type of modalias string.






            share|improve this answer
























            • This is a very good answer, very extensive and very informative. Thank you.

              – jedi
              Feb 11 at 13:36














            1












            1








            1







            (Based on Google-cached copy of http://people.skolelinux.org/pere/blog/Modalias_strings___a_practical_way_to_map__stuff__to_hardware.html by Petter Reinholdtsen.)



            In the hardware, there are certain standard device identifiers that can be accessed as long as you know the standard access method for that particular I/O bus or subsystem, without having any further knowledge about the actual device. In Linux, these identifiers are used to build up modalias strings, which are then used to find the correct driver for each device.



            The source code of each driver module can include MODULE_DEVICE_TABLE structures, which are used by the depmod command to create module alias wildcard entries that will match the modalias strings of the hardware supported by that particular module.



            When the kernel detects a piece of hardware with no matching driver loaded yet, it will create a modalias string from the identifiers of the hardware, and use it to request a module to be autoloaded. The modprobe command will then use the /lib/modules/$(uname -r)/modules.alias[.bin] file created by depmod to see if a matching module exists. If it does, that module is loaded and gets to probe the hardware for further details if necessary.



            For example, I have a DVB TV card:



            $ lspci -v -nn -s 07:00.0
            07:00.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 04)
            Subsystem: Hauppauge computer works Inc. CX23885 PCI Video and Audio Decoder [0070:6a28]


            This results in a modalias string like this:



            pci:v000014F1d00008852sv00000070sd00006A28bc04sc00i00


            The cx23885 module has these aliases based on MODULE_DEVICE_TABLE in its source code:



            # modinfo cx23885
            ...
            alias: pci:v000014F1d00008880sv*sd*bc*sc*i*
            alias: pci:v000014F1d00008852sv*sd*bc*sc*i*
            ...


            When the kernel detects the card, it effectively runs the modprobe pci:v000014F1d00008852sv00000070sd00006A28bc04sc00i00 command. The second alias of the cx23885 module matches, and so that module gets loaded.



            PCI/PCI-X/PCIe bus devices



            This is the "PCI subtype". It uses modalias strings like this:



            pci:v00008086d00002770sv00001028sd000001ADbc06sc00i00


            This can be decoded as follows:



            v   00008086  (vendor)
            d 00002770 (device)
            sv 00001028 (subvendor)
            sd 000001AD (subdevice)
            bc 06 (bus class)
            sc 00 (bus subclass)
            i 00 (interface)


            With lspci -nn, you can see the class, subclass, vendor and device IDs. If you add the -v option, you can also see the subvendor:subdevice IDs.



            USB devices



            With USB devices, the modalias strings look like this:



            usb:v1D6Bp0001d0206dc09dsc00dp00ic09isc00ip00


            This unpacks to:



            v    1D6B  (device vendor)
            p 0001 (device product)
            d 0206 (bcddevice)
            dc 09 (device class)
            dsc 00 (device subclass)
            dp 00 (device protocol)
            ic 09 (interface class)
            isc 00 (interface subclass)
            ip 00 (interface protocol)


            With the lsusb command, you can see the vendor and product IDs. If you use the -v option, you can see the other IDs too.



            ACPI devices



            These use the ACPI PNP identifiers, prefixed with acpi: and separated with colons:



            acpi:IBM0071:PNP0511:


            DMI devices



            This can be a very long modalias string:



            dmi:bvnIBM:bvr1UETB6WW(1.66):bd06/15/2005:svnIBM:pn2371H4G:pvrThinkPadX40:rvnIBM:rn2371H4G:rvrNotAvailable:cvnIBM:ct10:cvrNotAvailable:


            This unpacks to:



            bvn  IBM            (BIOS vendor)
            bvr 1UETB6WW(1.66) (BIOS version)
            bd 06/15/2005 (BIOS date)
            svn IBM (system vendor)
            pn 2371H4G (product name)
            pvr ThinkPadX40 (product version)
            rvn IBM (board vendor)
            rn 2371H4G (board name)
            rvr NotAvailable (board version)
            cvn IBM (chassis vendor)
            ct 10 (chassis type)
            cvr NotAvailable (chassis version)


            SerIO devices, i.e. mostly PS/2 mice



            The modalias string will look like this:



            serio:ty01pr00id00ex00


            The values here are:



            ty  01  (type)
            pr 00 (prototype)
            id 00 (id)
            ex 00 (extra)


            Other bus/device types



            There are many other bus types recognized by the Linux kernel. Studying the contents of the kernel source file file2alias.c might be helpful in deciphering the meaning of the components of each type of modalias string.






            share|improve this answer













            (Based on Google-cached copy of http://people.skolelinux.org/pere/blog/Modalias_strings___a_practical_way_to_map__stuff__to_hardware.html by Petter Reinholdtsen.)



            In the hardware, there are certain standard device identifiers that can be accessed as long as you know the standard access method for that particular I/O bus or subsystem, without having any further knowledge about the actual device. In Linux, these identifiers are used to build up modalias strings, which are then used to find the correct driver for each device.



            The source code of each driver module can include MODULE_DEVICE_TABLE structures, which are used by the depmod command to create module alias wildcard entries that will match the modalias strings of the hardware supported by that particular module.



            When the kernel detects a piece of hardware with no matching driver loaded yet, it will create a modalias string from the identifiers of the hardware, and use it to request a module to be autoloaded. The modprobe command will then use the /lib/modules/$(uname -r)/modules.alias[.bin] file created by depmod to see if a matching module exists. If it does, that module is loaded and gets to probe the hardware for further details if necessary.



            For example, I have a DVB TV card:



            $ lspci -v -nn -s 07:00.0
            07:00.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder [14f1:8852] (rev 04)
            Subsystem: Hauppauge computer works Inc. CX23885 PCI Video and Audio Decoder [0070:6a28]


            This results in a modalias string like this:



            pci:v000014F1d00008852sv00000070sd00006A28bc04sc00i00


            The cx23885 module has these aliases based on MODULE_DEVICE_TABLE in its source code:



            # modinfo cx23885
            ...
            alias: pci:v000014F1d00008880sv*sd*bc*sc*i*
            alias: pci:v000014F1d00008852sv*sd*bc*sc*i*
            ...


            When the kernel detects the card, it effectively runs the modprobe pci:v000014F1d00008852sv00000070sd00006A28bc04sc00i00 command. The second alias of the cx23885 module matches, and so that module gets loaded.



            PCI/PCI-X/PCIe bus devices



            This is the "PCI subtype". It uses modalias strings like this:



            pci:v00008086d00002770sv00001028sd000001ADbc06sc00i00


            This can be decoded as follows:



            v   00008086  (vendor)
            d 00002770 (device)
            sv 00001028 (subvendor)
            sd 000001AD (subdevice)
            bc 06 (bus class)
            sc 00 (bus subclass)
            i 00 (interface)


            With lspci -nn, you can see the class, subclass, vendor and device IDs. If you add the -v option, you can also see the subvendor:subdevice IDs.



            USB devices



            With USB devices, the modalias strings look like this:



            usb:v1D6Bp0001d0206dc09dsc00dp00ic09isc00ip00


            This unpacks to:



            v    1D6B  (device vendor)
            p 0001 (device product)
            d 0206 (bcddevice)
            dc 09 (device class)
            dsc 00 (device subclass)
            dp 00 (device protocol)
            ic 09 (interface class)
            isc 00 (interface subclass)
            ip 00 (interface protocol)


            With the lsusb command, you can see the vendor and product IDs. If you use the -v option, you can see the other IDs too.



            ACPI devices



            These use the ACPI PNP identifiers, prefixed with acpi: and separated with colons:



            acpi:IBM0071:PNP0511:


            DMI devices



            This can be a very long modalias string:



            dmi:bvnIBM:bvr1UETB6WW(1.66):bd06/15/2005:svnIBM:pn2371H4G:pvrThinkPadX40:rvnIBM:rn2371H4G:rvrNotAvailable:cvnIBM:ct10:cvrNotAvailable:


            This unpacks to:



            bvn  IBM            (BIOS vendor)
            bvr 1UETB6WW(1.66) (BIOS version)
            bd 06/15/2005 (BIOS date)
            svn IBM (system vendor)
            pn 2371H4G (product name)
            pvr ThinkPadX40 (product version)
            rvn IBM (board vendor)
            rn 2371H4G (board name)
            rvr NotAvailable (board version)
            cvn IBM (chassis vendor)
            ct 10 (chassis type)
            cvr NotAvailable (chassis version)


            SerIO devices, i.e. mostly PS/2 mice



            The modalias string will look like this:



            serio:ty01pr00id00ex00


            The values here are:



            ty  01  (type)
            pr 00 (prototype)
            id 00 (id)
            ex 00 (extra)


            Other bus/device types



            There are many other bus types recognized by the Linux kernel. Studying the contents of the kernel source file file2alias.c might be helpful in deciphering the meaning of the components of each type of modalias string.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Feb 10 at 13:38









            telcoMtelcoM

            18.2k12347




            18.2k12347













            • This is a very good answer, very extensive and very informative. Thank you.

              – jedi
              Feb 11 at 13:36



















            • This is a very good answer, very extensive and very informative. Thank you.

              – jedi
              Feb 11 at 13:36

















            This is a very good answer, very extensive and very informative. Thank you.

            – jedi
            Feb 11 at 13:36





            This is a very good answer, very extensive and very informative. Thank you.

            – jedi
            Feb 11 at 13:36


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f499716%2fhow-does-linux-know-how-and-what-drivers-to-install-in-a-new-installation%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            How to reconfigure Docker Trusted Registry 2.x.x to use CEPH FS mount instead of NFS and other traditional...

            is 'sed' thread safe

            How to make a Squid Proxy server?