From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (unknown [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id DC0FB1381FA for ; Wed, 21 May 2014 17:54:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 94E53E080A; Wed, 21 May 2014 17:54:06 +0000 (UTC) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 16269E0953 for ; Wed, 21 May 2014 17:54:04 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id p9so1840817lbv.35 for ; Wed, 21 May 2014 10:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=pORr3rK5WrQO9HbVZYuLTDzUVokqdmgC54yNKhPaOFw=; b=AuONWFDbLKbTMlaHIAswoPvaaaGmsATAlpIF7e6zRy6BUf451g9NigjVslArCWF2HJ Gt2viMtxrCPMeAoYcWTTwQv+ZspPq1yZPXUjA2YGsQA11Jkf8fVYEGHAUgxDWtKkgw+J ck6vZmy3tl/ZiBleoqheIO656rNLU4Kuhiq2PC0lx+WvfNlBbn9URhAAMk2IrHPUdL/E psJ2V1DufIq92AZcdwGAWY07njSl32eao95STJVzvDEI5iG8tovEaSaahnyYig/qHhS9 t4d2dudx30RKOofAjQSpHa/0UqLrVEjBVe5hngbj1gazFD17oYMaweUT2ltMY80/HyLm 4evg== X-Received: by 10.152.5.98 with SMTP id r2mr4185779lar.59.1400694843294; Wed, 21 May 2014 10:54:03 -0700 (PDT) Received: from [192.168.1.2] (213-154-212-42.static.vega-ua.net. [213.154.212.42]) by mx.google.com with ESMTPSA id f9sm26076405lae.16.2014.05.21.10.54.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 10:54:02 -0700 (PDT) Message-ID: <537CE8E1.7030504@gmail.com> Date: Wed, 21 May 2014 20:56:49 +0300 From: Alexander Kapshuk User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Having Trouble with Wireless Interface References: <45663147-8534-4475-94FB-E325A0E94CD5@stellar.eclipse.co.uk> <5374C029.2080105@gmail.com> <201405152050.13159.michaelkintzios@gmail.com> <53780749.9060907@gentoo.org> In-Reply-To: <53780749.9060907@gentoo.org> Content-Type: multipart/alternative; boundary="------------050201080209070402060303" X-Archives-Salt: ccef579c-9667-4d69-9242-1e41d85ed096 X-Archives-Hash: fea1b1361bc982343e68eec859c68398 This is a multi-part message in MIME format. --------------050201080209070402060303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 > > 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. --------------050201080209070402060303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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.kapshuk@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.

--------------050201080209070402060303--