[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200902071254.28824.rusty@rustcorp.com.au>
Date: Sat, 7 Feb 2009 12:54:28 +1030
From: Rusty Russell <rusty@...tcorp.com.au>
To: Shawn Bohrer <shawn.bohrer@...il.com>
Cc: linux-kernel@...r.kernel.org, Jon Masters <jonathan@...masters.org>
Subject: Re: [PATCH 5/6] module: make modversion_info contain a pointer, not an array.
On Friday 06 February 2009 02:31:28 Shawn Bohrer wrote:
> On Thu, Jan 29, 2009 at 12:05:52AM +1030, Rusty Russell wrote:
> > With allmodconfig (minus non-building modules) on 32-bit x86:
> > Total size of modules before: 60009790 bytes
> > Total size of modules after: 55927866 bytes
> >
> > Saving 7% of module size for CONFIG_MODVERSIONS=y; and these sections
> > are kept resident as well.
> >
> > Signed-off-by: Rusty Russell <rusty@...tcorp.com.au>
> > ---
> > include/linux/module.h | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/module.h b/include/linux/module.h
> > --- a/include/linux/module.h
> > +++ b/include/linux/module.h
> > @@ -37,10 +37,12 @@ struct kernel_symbol
> > const char *name;
> > };
> >
> > +/* This is put in the __versions section of a module to indicate the version
> > + * it expects for unknown symbols. */
> > struct modversion_info
> > {
> > unsigned long crc;
> > - char name[MODULE_NAME_LEN];
> > + char *name;
> > };
>
> Hey Rusty thanks for the change, but I just got around to testing this
> and I have a few observations/questions. First this breaks:
>
> modprobe --dump-modversions foo.ko
Hmm, that's an argument not to make this change. Really, other than disk
space benefit we get all the benefits from just dropping the
__versions section once loaded.
> I actually don't care, but just happened to stumble upon it when I also
> noticed that your changes seemed to be working a little too well. I
> currently happen to be building my modules out of order for example
> module B depends on symbols from module A, but I build module B first.
> This means that the exported symbols are not in the Module.symvers file
> when module B is compiled. I would expect module B to fail to load yet
> with your patches it magically works and I don't see any errors in the
> logs.
Interesting. What is the value of /proc/sys/kernel/tainted?
And anyway, what was the symbol name which is over 56 characters long which
started this?
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists