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