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