All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Hans Beckerus <hans.beckerus@gmail.com>
Cc: yocto@yoctoproject.org
Subject: Re: How do I control what kernel modules are being loaded?
Date: Fri, 8 Mar 2013 18:45:58 -0500	[thread overview]
Message-ID: <513A7836.2050908@windriver.com> (raw)
In-Reply-To: <513A3557.10405@gmail.com>

On 13-03-08 2:00 PM, Hans Beckerus wrote:
> On 2013-03-08 7:12, Eric Bénard wrote:
>> Hi Hans,
>>
>> Le Fri, 8 Mar 2013 13:08:21 +0100,
>> Hans Beckérus <hans.beckerus@gmail.com> a écrit :
>>
>>> Hi. I have built some custom kernel modules (.ko) using a .bb that
>>> inherits from the module.bbclass. There is one main kernel module and
>>> the rest are dependent on the first. Building and installing the
>>> modules to the rootfs works fine. Next question is how do I control
>>> what actual modules are loaded at boot, or actually how do I control
>>> this through Yocto? To my surprise one of the kernel module loaded
>>> automatically!? How could this happen? I did not have an entry for it
>>> in /etc/modules. And what do I need to do to actually add entries to
>>> /etc/modules? Or is there some other mechanism that I should use. I
>>> tried going through the module.bbclass but must admit I lost it
>>> somewhere in the middle ;) Any guidance would be appreciated.
>>>
>> when the module is built by the kernel recipe you can use :
>> module_autoload and you can see somme usage examples here :
>> http://cgit.openembedded.org/meta-handheld/tree/conf/machine/palmtx.conf
>> http://cgit.openembedded.org/meta-handheld/tree/conf/machine/include/palm.inc
>>
>>
>> maybe you could get inspiration from kernel.bbclass to do the same
>> thing in your recipe.
>>
>> Eric
> Thanks guys for your quick feedback. I can see that using
> module_autoload_${PN} seems like a good approach, if a package maps 1:1
> to a module.
> In my case that is not so. The package/recipe builds six (or even more)
> .ko files using one makefile.
> I guess one option could be to split each module build in its own
> recipe, but that is not supported by the makefile and thus would require
> patching from my side in the source tree. I think the only option I have
> left is to try to use /etc/modules and add the modules there in a
> do_install_append().
> But the problem then is, what happens if some other package also add a
> /etc/modules.conf to the image folder? Will it be merged or only copied?
> In the latter case last package wins which would not work out very well :(
>
> Out of curiosity, what will module_autoload do? Will it add the .ko to
> /etc/modules or does it implement some other mechanism to make a module
> load automatically at boot?

It depends on what release you are using. In yocto 1.3 and before the
autoload variables translated to mod-util loading, using just what you'd
think. In yocto 1.4 and kmod in the picture:

         # If autoloading is requested, output 
/etc/modules-load.d/<name>.conf and append
         # appropriate modprobe commands to the postinst
         autoload = d.getVar('module_autoload_%s' % basename, True)
         if autoload:
             name = '%s/etc/modules-load.d/%s.conf' % (dvar, basename)
             f = open(name, 'w')
             for m in autoload.split():
                 f.write('%s\n' % m)
             f.close()
             postinst = d.getVar('pkg_postinst_%s' % pkg, True)
             if not postinst:
                 bb.fatal("pkg_postinst_%s not defined" % pkg)
             postinst += d.getVar('autoload_postinst_fragment', True) % 
autoload
             d.setVar('pkg_postinst_%s' % pkg, postinst)

         # Write out any modconf fragment
         modconf = d.getVar('module_conf_%s' % basename, True)
         if modconf:
             name = '%s/etc/modprobe.d/%s.conf' % (dvar, basename)
             f = open(name, 'w')
             f.write("%s\n" % modconf)
             f.close()

Cheers,

Bruce


>
> I do not think that the mandatory module that is loaded originates from
> udev. This is a network CM driver that basically hooks into the Linux
> network stack. I do not think that udev will ever make this driver load
> automatically. But I can not say for sure of course.
>
> Hans
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



  reply	other threads:[~2013-03-08 23:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-08 12:08 How do I control what kernel modules are being loaded? Hans Beckérus
2013-03-08 17:12 ` Bruce Ashfield
2013-03-08 17:40   ` Hans Beckérus
2013-03-08 17:45     ` Bruce Ashfield
2013-03-08 18:12 ` Eric Bénard
2013-03-08 19:00   ` Hans Beckerus
2013-03-08 23:45     ` Bruce Ashfield [this message]
     [not found]       ` <CAFyqS9rT=amDBNTO_awzXL3zNS-vCx1+0ERCspXTps8u_VpHwA@mail.gmail.com>
2013-03-11 13:28         ` Hans Beckérus
2013-03-11 13:37           ` Bruce Ashfield
2013-03-11 13:46             ` Eric Bénard
2013-03-11 13:49               ` Bruce Ashfield
2013-03-11 13:49             ` Eric Bénard
2013-03-11 18:36               ` Hans Beckerus
2013-03-08 21:11   ` Hans Beckerus
2013-03-08 19:16 ` Trevor Woerner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=513A7836.2050908@windriver.com \
    --to=bruce.ashfield@windriver.com \
    --cc=hans.beckerus@gmail.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.