Re: [gentoo-user] Re: Having Trouble with Wireless Interface
On 05/22/2014 06:34 AM, Jonathan Callen wrote: On 05/21/2014 01:56 PM, Alexander Kapshuk wrote: Thanks for the explanation. Just to double check I understood it correctly, there's no need to put the list of kernel modules into /etc/conf.d/modules any longer, because udev is aware of the modules that have been built and will load them by consulting /lib/modules/$(uname -r)/modules.alias. Is that correct? Thanks. You only need to list the modules in /etc/conf.d/modules (for OpenRC) or /etc/modules-load.d/*.conf (for systemd) if they would not otherwise be loaded. Just about any module that provides a driver for hardware that can be autodetected (that is, PCI, USB, etc.) will be auto-loaded by udev. Modules used to provide filters, etc. for iptables are autoloaded by iptables itself as needed. Some modules do not have anything that would cause them to be autoloaded (such as the vbox-* modules from VirtualBox), in which case you *would* need to explicitly load them. Understood. Thanks to all those who did respond to my query.
Re: [gentoo-user] Re: Having Trouble with Wireless Interface
On 05/18/2014 04:05 AM, Jonathan Callen wrote:
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:v8086d0416sv1558sd7104bc03sc00i00
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 8086
d 0416
sv 1558
sd 7104
bc 03
sc 00
i 00
In this case I have vendor 8086 (Intel Corporation), device
0416 (4th Gen Core Processor Integrated Graphics Controller),
subsystem vendor 1558 (CLEVO/KAPOK Computer), subsystem device
7104 (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:v8086d0416sv*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.
Thanks for the explanation.
Just to double check I understood it correctly, there's no need to put
the list of kernel modules into /etc/conf.d/modules any longer, because
udev is aware of the modules that have been built and will load them by
consulting /lib/modules/$(uname -r)/modules.alias. Is that correct?
Thanks.
Re: [gentoo-user] Re: Having Trouble with Wireless Interface
On Wednesday 21 May 2014 18:56:49 Alexander Kapshuk wrote:
On 05/18/2014 04:05 AM, Jonathan Callen wrote:
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:v8086d0416sv1558sd7104bc03sc00i00
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 8086
d 0416
sv 1558
sd 7104
bc 03
sc 00
i 00
In this case I have vendor 8086 (Intel Corporation), device
0416 (4th Gen Core Processor Integrated Graphics Controller),
subsystem vendor 1558 (CLEVO/KAPOK Computer), subsystem device
7104 (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:v8086d0416sv*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.
Thanks for the explanation.
Just to double check I understood it correctly, there's no need to put
the list of kernel modules into /etc/conf.d/modules any longer, because
udev is aware of the modules that have been built and will load them by
consulting /lib/modules/$(uname -r)/modules.alias. Is that correct?
Thanks.
No, it is incorrect, or I better say incomplete. There are some modules
(netfilter, virtualbox, et al.) which will not be autoloaded. You will need
to add those in your /etc/conf.d/modules and make sure the syntax is correct
for the kernel version that you intend to boot with.
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
[gentoo-user] Re: Having Trouble with Wireless Interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/21/2014 01:56 PM, Alexander Kapshuk wrote: Thanks for the explanation. Just to double check I understood it correctly, there's no need to put the list of kernel modules into /etc/conf.d/modules any longer, because udev is aware of the modules that have been built and will load them by consulting /lib/modules/$(uname -r)/modules.alias. Is that correct? Thanks. You only need to list the modules in /etc/conf.d/modules (for OpenRC) or /etc/modules-load.d/*.conf (for systemd) if they would not otherwise be loaded. Just about any module that provides a driver for hardware that can be autodetected (that is, PCI, USB, etc.) will be auto-loaded by udev. Modules used to provide filters, etc. for iptables are autoloaded by iptables itself as needed. Some modules do not have anything that would cause them to be autoloaded (such as the vbox-* modules from VirtualBox), in which case you *would* need to explicitly load them. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTfXBLAAoJELHSF2kinlg4TQ0QAKGDJ3ZFZOeK8Y4hEE6xGMXV f2vjjAUhyrR2J67vwA5eJ377ZxF5ieMvY8N4sTk68hlLDWZrAGmfLs5u+d9gbqaO 3dF6ekvnebdH9apQ2xdCpaWD/AlfeZ8JR1Mav3kYkjaurGeMkNN3cqZAzkaip8gZ jJ1TWRy74+jJFv2F904/pjShKKEl+BEssLcSSFr91Jx70fNKiby+1oJfhZIcm4Kj 8KMLz/sh7BB6ia0KnEnNM2P11zRct+4ParXIAhCxT2P/x5DvOHGbgMie27k8VY1J 8v8LjbqCAZS43In6Vr07IfMwy0wNQAkob6GkGytyiIcijSdVDINkwSomcSS1Madb xWTWX1gEqogHtQoe3GkaW2H+nksZejtJwt5FzQsUmEDytNA5kqef7UiW1rV6rXE5 Uz94OZiopQTyrXYtnZHsCnY0JGu4DnCvm+JLSh5ee1VDRs8aPX22pWjCEtat1q9c +QKTVW62D32zC8cgLH04Hgbc6zN3/J3akTJftZRSISqMCA1xQwe0wyZet2RKVJUo anyC/lOh2mIp9zCTUvTt81oUpElTPKN4l7UjDuPoLK7n4oOK2Ao9frPeEoDxJGam 0fhlOwAg5PpV4qSyWQGneg96UlirB9O9mai/wEzzOZPxaY9gu/scqXrPUZWGwQbp BpEgVnDCGLTpZE6cqfu1 =SJpi -END PGP SIGNATURE-
[gentoo-user] Re: Having Trouble with Wireless Interface
-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:v8086d0416sv1558sd7104bc03sc00i00
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 8086
d 0416
sv 1558
sd 7104
bc 03
sc 00
i 00
In this case I have vendor 8086 (Intel Corporation), device
0416 (4th Gen Core Processor Integrated Graphics Controller),
subsystem vendor 1558 (CLEVO/KAPOK Computer), subsystem device
7104 (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:v8086d0416sv*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-
