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