-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 05/15/2014 03:50 PM, Mick wrote:
> On Thursday 15 May 2014 14:24:57 Alexander Kapshuk wrote:
>> On 05/15/2014 11:39 AM, Stroller wrote:
>>> On Wed, 14 May 2014, at 12:36 pm, Alexander Kapshuk
> <alexander.kaps...@gmail.com> wrote:
>>>>>> …
>>>>>> If you like to check if RTL8192CE is enabled in your kernel's .config
>>>>>> file. If it isn't, you probably want to compile it as a module, and
>>>>>> then add rtl8192ce to /etc/conf.d/modules as well.
>>>>>
>>>>> Am pretty sure there's no need to add this one to /etc/conf.d/modules -
>>>>> IME it'll just be found and loaded automagically by the kernel.
>>>>
>>>> Thanks for pointing that out. I wasn't aware of that. As I mentioned in
>>>> my previous post, I do not use genkernel myself.
>>>
>>> Neither do I - for this reason I found it a little frustrating trying to
>>> help in a recent thread, myself.
>>>
>>> However, I'm pretty sure that loadable kernel modules behave the same
>>> whether your kernel is built "by hand" or by genkernel - if you have
>>> modules listed in /etc/conf.d/modules then I have to wonder if you
>>> really need them there.
>>>
>>> I haven't used that file for years, and I prefer to compile everything as
>>> a module, too.
>>>
>>> Stroller.
>>
>> That's interesting. I wasn't aware of that either.
>>
>> So far, I've just been following the instructions given in the handbook,
>> section 7.d, which do recommend explicitly specifying the kernel modules
>> to be loaded at boot time in /etc/conf.d/modules.
>>
>> How does the kernel know then what modules to load at boot time, if it
>> doesn't rely on /etc/conf.d/modules to supply the list of modules to be
>> loaded?
>>
>> Does it use udev, or some other mechanism for that?
>>
>> Thanks.
>
> I understand it is udev magic which probes the hardware and it fetches the
> corresponding module from the kernel, as long as it has been compiled.
> Incidentally, I noticed that I now have this running on my system:
>
> /lib/systemd/systemd-udevd --daemon
>
The actual udev magic in question is this line from
/lib/udev/rules.d/80-drivers.rules:
ENV{MODALIAS}=="?*", RUN{builtin}+="kmod load $env{MODALIAS}"
When a new device is seen by the kernel (which includes cold-plug on
boot), udev calls the equivalent of `modprobe ${MODALIAS}` (in reality,
the actual command is now just a call to libkmod, which is linked into
udev itself), where ${MODALIAS} is the contents of the file "modalias"
under the /sys directory describing that device. This file may look
something like this (actual example from my machine):
pci:v00008086d00000416sv00001558sd00007104bc03sc00i00
This information (following the the initial "pci:", indicating that this
is a PCI device), can be split into multiple identifier/number pairs,
like so:
v 00008086
d 00000416
sv 00001558
sd 00007104
bc 03
sc 00
i 00
In this case I have vendor "00008086" (Intel Corporation), device
"00000416" (4th Gen Core Processor Integrated Graphics Controller),
subsystem vendor "00001558" (CLEVO/KAPOK Computer), subsystem device
"00007104" (not listed in pci.ids, sorry), base class "03" (Display
controller), sub class "00" (VGA compatible controller), and programming
interface "00" (VGA controller).
This information is then used to look up the module in
/lib/modules/$(uname -r)/modules.alias (actually, modules.alias.bin is
used if present to speed up the lookup). This lookup finds the line:
alias pci:v00008086d00000416sv*sd*bc03sc*i* i915
As my card matches the glob in the second field in that line, the module
listed in the third field is loaded to handle the card. The actual
modules.alias file is generated by depmod when the module is installed
by reading the information from the module itself.
- --
Jonathan Callen
123456789012345678901234567890123456789012345678901234567890123456789012
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJTeAdJAAoJELHSF2kinlg42aAP/ih0j0GdrC7FEY79MH4wg/YN
Wv7lwfNRjETmMO9KpnOUXm5rphBc6j7nI4JVmaBbKB3MOk4CbqQWulfsqcuOKkU6
cuszlbq3Rkhauq4e9dn1/oF6jjxspe0oKjbsEzMD0UVpFlEJC+WVXph82yuJN0MC
5QcDkJLSZSubeupBiLDL1iQIpPNyUVfAAB8iYAn1HAzQ20RDk32k62rBVg3dHrUx
9DCZV5SepEhhtSfFqk3nDCZp0FlRmnFmKCsEVAuhuuSLn5lZxaaY5gFiFENmi3Yf
tyhJEDkBAVZJaISccWCpMhMrqGCdvnNghuCgt4qjXaOIsfSA85YkocYq+nAXTxx4
W+6N2K7jl8Ophlmqx63dSqlMMquCNNGWPY03cAC0zFddQgX7Twyshie+xP69Ze8J
0AhFQUy6i5JSWN7gNWExK/9BbegEiLF5jQr7GTbiGpciP6cxCF7AQlUXopbBQcLN
UoOdATw1YMe6C4dTTEIRoT6tNirLkdKLuWay0nnz1wiXA09NOtPdfXjBm4eFcHWb
TI0OybeYnJFTrplm6QHwqpbDik9Fo/ujaK3NZfbVIMwgIngXPn02jkRsBsSomyN/
Awnowz0MdHQODVND+mekguHHo1eHnirwNFbJeES6qrbHK3sezPuglpS5C3tZWnI3
9DlwT27j8A4YYl0LugkD
=Oswq
-----END PGP SIGNATURE-----
