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: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.
>
>
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.
