From: Rusty Russell <rusty@rustcorp.com.au>
To: Barry Davis <barry_davis@stormagic.com>
Cc: Tom Gundersen <teg@jklm.no>, "lkml" <linux-kernel@vger.kernel.org>
Subject: Re: 0003-module-remove-MODULE_GENERIC_TABLE.patch
Date: Mon, 20 Oct 2014 10:58:17 +1030 [thread overview]
Message-ID: <87y4sb8tzy.fsf@rustcorp.com.au> (raw)
In-Reply-To: <EF6418FA9E2C4C238A5A1FB4BE9FF408@vWin7>
Barry Davis <barry_davis@stormagic.com> writes:
> Hi Rusty,
>
> I’ve just been looking at a change that this patch says you introduced:
>
> https://github.com/jumpstarter-io/pkgbuilds/blob/master/linux/0003-module-remove-MODULE_GENERIC_TABLE.patch
>
> In previous kernels we had this defined:
> chroot:# nm kernel/drivers/scsi/vmw_pvscsi.ko | grep _device_table
> 000000e0 R __mod_pci_device_table
>
> Now we have:
> chroot:# nm kernel/drivers/scsi/vmw_pvscsi.ko | grep _device_table
> 000000e0 R __mod_pci__pvscsi_pci_tbl_device_table
>
> This results in depmod from module-init-tools not being able to find the __mod_pci_device_table.
> This leads to modules.pcimap being generated with no entries, which breaks anything that uses modules.pcimap to decide if it should insert a module or not.
>
> Was this unintentional, or is there another way to successfully generate modules.pcimap?
>
> See https://github.com/vadmium/module-init-tools/blob/master/elfops_core.c#L351 for details of depmods expectations.
Hi Barry,
Not intentional at all! You're the first to report this though:
are you still using the (deprecated) modules.pcimap? The *map files are
not supported by kmod, and were only inserted as a nod to the older
modutils.
Because it's really hard to fix: we now allow multiple tables, so the
names are now unique.
commit cff26a51da5d206d3baf871e75778da44710219d is the one that broke
this, but commit 21bdd17b21b45ea48e06e23918d681afbe0622e9 relies on it:
commit 21bdd17b21b45ea48e06e23918d681afbe0622e9
Author: Tom Gundersen <teg@jklm.no>
Date: Mon Feb 3 11:14:13 2014 +1030
module: allow multiple calls to MODULE_DEVICE_TABLE() per module
Commit 78551277e4df5: "Input: i8042 - add PNP modaliases" had a bug, where the
second call to MODULE_DEVICE_TABLE() overrode the first resulting in not all
the modaliases being exposed.
This fixes the problem by including the name of the device_id table in the
__mod_*_device_table alias, allowing us to export several device_id tables
per module.
Suggested-by: Kay Sievers <kay@vrfy.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
parent reply other threads:[~2014-10-20 0:34 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <EF6418FA9E2C4C238A5A1FB4BE9FF408@vWin7>]
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=87y4sb8tzy.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=barry_davis@stormagic.com \
--cc=linux-kernel@vger.kernel.org \
--cc=teg@jklm.no \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).