| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA512 |
| 3 |
|
| 4 |
On 05/15/2014 03:50 PM, Mick wrote: |
| 5 |
> On Thursday 15 May 2014 14:24:57 Alexander Kapshuk wrote: |
| 6 |
>> On 05/15/2014 11:39 AM, Stroller wrote: |
| 7 |
>>> On Wed, 14 May 2014, at 12:36 pm, Alexander Kapshuk |
| 8 |
> <alexander.kapshuk@×××××.com> wrote: |
| 9 |
>>>>>> … |
| 10 |
>>>>>> If you like to check if RTL8192CE is enabled in your kernel's .config |
| 11 |
>>>>>> file. If it isn't, you probably want to compile it as a module, and |
| 12 |
>>>>>> then add rtl8192ce to /etc/conf.d/modules as well. |
| 13 |
>>>>> |
| 14 |
>>>>> Am pretty sure there's no need to add this one to /etc/conf.d/modules - |
| 15 |
>>>>> IME it'll just be found and loaded automagically by the kernel. |
| 16 |
>>>> |
| 17 |
>>>> Thanks for pointing that out. I wasn't aware of that. As I mentioned in |
| 18 |
>>>> my previous post, I do not use genkernel myself. |
| 19 |
>>> |
| 20 |
>>> Neither do I - for this reason I found it a little frustrating trying to |
| 21 |
>>> help in a recent thread, myself. |
| 22 |
>>> |
| 23 |
>>> However, I'm pretty sure that loadable kernel modules behave the same |
| 24 |
>>> whether your kernel is built "by hand" or by genkernel - if you have |
| 25 |
>>> modules listed in /etc/conf.d/modules then I have to wonder if you |
| 26 |
>>> really need them there. |
| 27 |
>>> |
| 28 |
>>> I haven't used that file for years, and I prefer to compile everything as |
| 29 |
>>> a module, too. |
| 30 |
>>> |
| 31 |
>>> Stroller. |
| 32 |
>> |
| 33 |
>> That's interesting. I wasn't aware of that either. |
| 34 |
>> |
| 35 |
>> So far, I've just been following the instructions given in the handbook, |
| 36 |
>> section 7.d, which do recommend explicitly specifying the kernel modules |
| 37 |
>> to be loaded at boot time in /etc/conf.d/modules. |
| 38 |
>> |
| 39 |
>> How does the kernel know then what modules to load at boot time, if it |
| 40 |
>> doesn't rely on /etc/conf.d/modules to supply the list of modules to be |
| 41 |
>> loaded? |
| 42 |
>> |
| 43 |
>> Does it use udev, or some other mechanism for that? |
| 44 |
>> |
| 45 |
>> Thanks. |
| 46 |
> |
| 47 |
> I understand it is udev magic which probes the hardware and it fetches the |
| 48 |
> corresponding module from the kernel, as long as it has been compiled. |
| 49 |
> Incidentally, I noticed that I now have this running on my system: |
| 50 |
> |
| 51 |
> /lib/systemd/systemd-udevd --daemon |
| 52 |
> |
| 53 |
|
| 54 |
The actual udev magic in question is this line from |
| 55 |
/lib/udev/rules.d/80-drivers.rules: |
| 56 |
|
| 57 |
ENV{MODALIAS}=="?*", RUN{builtin}+="kmod load $env{MODALIAS}" |
| 58 |
|
| 59 |
When a new device is seen by the kernel (which includes cold-plug on |
| 60 |
boot), udev calls the equivalent of `modprobe ${MODALIAS}` (in reality, |
| 61 |
the actual command is now just a call to libkmod, which is linked into |
| 62 |
udev itself), where ${MODALIAS} is the contents of the file "modalias" |
| 63 |
under the /sys directory describing that device. This file may look |
| 64 |
something like this (actual example from my machine): |
| 65 |
|
| 66 |
pci:v00008086d00000416sv00001558sd00007104bc03sc00i00 |
| 67 |
|
| 68 |
This information (following the the initial "pci:", indicating that this |
| 69 |
is a PCI device), can be split into multiple identifier/number pairs, |
| 70 |
like so: |
| 71 |
|
| 72 |
v 00008086 |
| 73 |
d 00000416 |
| 74 |
sv 00001558 |
| 75 |
sd 00007104 |
| 76 |
bc 03 |
| 77 |
sc 00 |
| 78 |
i 00 |
| 79 |
|
| 80 |
In this case I have vendor "00008086" (Intel Corporation), device |
| 81 |
"00000416" (4th Gen Core Processor Integrated Graphics Controller), |
| 82 |
subsystem vendor "00001558" (CLEVO/KAPOK Computer), subsystem device |
| 83 |
"00007104" (not listed in pci.ids, sorry), base class "03" (Display |
| 84 |
controller), sub class "00" (VGA compatible controller), and programming |
| 85 |
interface "00" (VGA controller). |
| 86 |
|
| 87 |
This information is then used to look up the module in |
| 88 |
/lib/modules/$(uname -r)/modules.alias (actually, modules.alias.bin is |
| 89 |
used if present to speed up the lookup). This lookup finds the line: |
| 90 |
|
| 91 |
alias pci:v00008086d00000416sv*sd*bc03sc*i* i915 |
| 92 |
|
| 93 |
As my card matches the glob in the second field in that line, the module |
| 94 |
listed in the third field is loaded to handle the card. The actual |
| 95 |
modules.alias file is generated by depmod when the module is installed |
| 96 |
by reading the information from the module itself. |
| 97 |
|
| 98 |
- -- |
| 99 |
Jonathan Callen |
| 100 |
123456789012345678901234567890123456789012345678901234567890123456789012 |
| 101 |
-----BEGIN PGP SIGNATURE----- |
| 102 |
Version: GnuPG v2.0.22 (GNU/Linux) |
| 103 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
| 104 |
|
| 105 |
iQIcBAEBCgAGBQJTeAdJAAoJELHSF2kinlg42aAP/ih0j0GdrC7FEY79MH4wg/YN |
| 106 |
Wv7lwfNRjETmMO9KpnOUXm5rphBc6j7nI4JVmaBbKB3MOk4CbqQWulfsqcuOKkU6 |
| 107 |
cuszlbq3Rkhauq4e9dn1/oF6jjxspe0oKjbsEzMD0UVpFlEJC+WVXph82yuJN0MC |
| 108 |
5QcDkJLSZSubeupBiLDL1iQIpPNyUVfAAB8iYAn1HAzQ20RDk32k62rBVg3dHrUx |
| 109 |
9DCZV5SepEhhtSfFqk3nDCZp0FlRmnFmKCsEVAuhuuSLn5lZxaaY5gFiFENmi3Yf |
| 110 |
tyhJEDkBAVZJaISccWCpMhMrqGCdvnNghuCgt4qjXaOIsfSA85YkocYq+nAXTxx4 |
| 111 |
W+6N2K7jl8Ophlmqx63dSqlMMquCNNGWPY03cAC0zFddQgX7Twyshie+xP69Ze8J |
| 112 |
0AhFQUy6i5JSWN7gNWExK/9BbegEiLF5jQr7GTbiGpciP6cxCF7AQlUXopbBQcLN |
| 113 |
UoOdATw1YMe6C4dTTEIRoT6tNirLkdKLuWay0nnz1wiXA09NOtPdfXjBm4eFcHWb |
| 114 |
TI0OybeYnJFTrplm6QHwqpbDik9Fo/ujaK3NZfbVIMwgIngXPn02jkRsBsSomyN/ |
| 115 |
Awnowz0MdHQODVND+mekguHHo1eHnirwNFbJeES6qrbHK3sezPuglpS5C3tZWnI3 |
| 116 |
9DlwT27j8A4YYl0LugkD |
| 117 |
=Oswq |
| 118 |
-----END PGP SIGNATURE----- |
Archives