Hi:
Finally found the cause of the section mismatch warning in hwrng.
Apparently in addition to __devexit_p we now have to name the
variable in a certain way.
I'll add this patch.
commit 8afb602bb676ed7da3cba154f2f5edf3971a582b
Author: Herbert Xu <[email protected]>
Date: Fri Dec 11 23:35:06 2009 +0800
hwrng: virtio - Rename driver object to remove section mismatch warning
The section mismatch warning shows up unless the __devexit referencing
variable is named in a certain way.
Signed-off-by: Herbert Xu <[email protected]>
diff --git a/drivers/char/hw_random/virtio-rng.c b/drivers/char/hw_random/virtio-rng.c
index bdaef8e..64fe0a7 100644
--- a/drivers/char/hw_random/virtio-rng.c
+++ b/drivers/char/hw_random/virtio-rng.c
@@ -114,7 +114,7 @@ static struct virtio_device_id id_table[] = {
{ 0 },
};
-static struct virtio_driver virtio_rng = {
+static struct virtio_driver virtio_rng_driver = {
.driver.name = KBUILD_MODNAME,
.driver.owner = THIS_MODULE,
.id_table = id_table,
@@ -124,12 +124,12 @@ static struct virtio_driver virtio_rng = {
static int __init init(void)
{
- return register_virtio_driver(&virtio_rng);
+ return register_virtio_driver(&virtio_rng_driver);
}
static void __exit fini(void)
{
- unregister_virtio_driver(&virtio_rng);
+ unregister_virtio_driver(&virtio_rng_driver);
}
module_init(init);
module_exit(fini);
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, 2009-12-11 at 23:36 +0800, Herbert Xu wrote:
> Hi:
>
> Finally found the cause of the section mismatch warning in hwrng.
> Apparently in addition to __devexit_p we now have to name the
> variable in a certain way.
That's fairly appalling. Any idea why?
--
http://selenic.com : development and support for Mercurial and Linux
On Fri, 11 Dec 2009 13:25:57 -0600 Matt Mackall wrote:
> On Fri, 2009-12-11 at 23:36 +0800, Herbert Xu wrote:
> > Hi:
> >
> > Finally found the cause of the section mismatch warning in hwrng.
> > Apparently in addition to __devexit_p we now have to name the
> > variable in a certain way.
>
> That's fairly appalling. Any idea why?
(I haven't read the rest of this thread..)
scripts/mod/modpost.c looks for certain variable names to identify
variables that can have references to other (non-data) sections.
It's mostly explained there.
(added cc: Sam)
---
~Randy
On Fri, Dec 11, 2009 at 12:08:49PM -0800, Randy Dunlap wrote:
> On Fri, 11 Dec 2009 13:25:57 -0600 Matt Mackall wrote:
>
> > On Fri, 2009-12-11 at 23:36 +0800, Herbert Xu wrote:
> > > Hi:
> > >
> > > Finally found the cause of the section mismatch warning in hwrng.
> > > Apparently in addition to __devexit_p we now have to name the
> > > variable in a certain way.
> >
> > That's fairly appalling. Any idea why?
>
> (I haven't read the rest of this thread..)
>
> scripts/mod/modpost.c looks for certain variable names to identify
> variables that can have references to other (non-data) sections.
> It's mostly explained there.
Another option is to annotate the relevant variable.
>From init.h:
/* modpost check for section mismatches during the kernel build.
* A section mismatch happens when there are references from a
* code or data section to an init section (both code or data).
* The init sections are (for most archs) discarded by the kernel
* when early init has completed so all such references are potential bugs.
* For exit sections the same issue exists.
* The following markers are used for the cases where the reference to
* the *init / *exit section (code or data) is valid and will teach
* modpost not to issue a warning.
* The markers follow same syntax rules as __init / __initdata. */
#define __ref __section(.ref.text) noinline
#define __refdata __section(.ref.data)
#define __refconst __section(.ref.rodata)
Sam
On Sat, 2009-12-12 at 01:21 +0100, Sam Ravnborg wrote:
> On Fri, Dec 11, 2009 at 12:08:49PM -0800, Randy Dunlap wrote:
> > On Fri, 11 Dec 2009 13:25:57 -0600 Matt Mackall wrote:
> >
> > > On Fri, 2009-12-11 at 23:36 +0800, Herbert Xu wrote:
> > > > Hi:
> > > >
> > > > Finally found the cause of the section mismatch warning in hwrng.
> > > > Apparently in addition to __devexit_p we now have to name the
> > > > variable in a certain way.
> > >
> > > That's fairly appalling. Any idea why?
> >
> > (I haven't read the rest of this thread..)
> >
> > scripts/mod/modpost.c looks for certain variable names to identify
> > variables that can have references to other (non-data) sections.
> > It's mostly explained there.
>
> Another option is to annotate the relevant variable.
Ok, I guess I knew about the annotations. So I take it the name magic
exists just for convenience or to hit the common cases?
--
http://selenic.com : development and support for Mercurial and Linux
On Fri, Dec 11, 2009 at 06:33:17PM -0600, Matt Mackall wrote:
> On Sat, 2009-12-12 at 01:21 +0100, Sam Ravnborg wrote:
> > On Fri, Dec 11, 2009 at 12:08:49PM -0800, Randy Dunlap wrote:
> > > On Fri, 11 Dec 2009 13:25:57 -0600 Matt Mackall wrote:
> > >
> > > > On Fri, 2009-12-11 at 23:36 +0800, Herbert Xu wrote:
> > > > > Hi:
> > > > >
> > > > > Finally found the cause of the section mismatch warning in hwrng.
> > > > > Apparently in addition to __devexit_p we now have to name the
> > > > > variable in a certain way.
> > > >
> > > > That's fairly appalling. Any idea why?
> > >
> > > (I haven't read the rest of this thread..)
> > >
> > > scripts/mod/modpost.c looks for certain variable names to identify
> > > variables that can have references to other (non-data) sections.
> > > It's mostly explained there.
> >
> > Another option is to annotate the relevant variable.
>
> Ok, I guess I knew about the annotations. So I take it the name magic
> exists just for convenience or to hit the common cases?
The name magic was introduced first - and by this we covered a
lot of common cases.
But we could not rename everything and thus we invented
the annotation.
The annotation ar preferable to the name magic becuse they
1) follow the usual way to tell that something is special
2) that it documents that this data structure have deliberate
access to *init/*exit sections
So the preference should be to use annotations over name magic.
[Maybe text from modpost needs an update to reflect this...]
Sam