|| ||Rusty Russell <rusty-AT-rustcorp.com.au>|
|| ||Shawn Bohrer <shawn.bohrer-AT-gmail.com>|
|| ||Re: Modversions and long symbol names|
|| ||Wed, 28 Jan 2009 23:38:56 +1030|
|| ||Article, Thread
On Wednesday 21 January 2009 04:06:36 Shawn Bohrer wrote:
> Currently when modversions is enabled the kernel will not load any
> modules that depend on exported symbols with names longer than
> 64 - sizeof(unsigned long) characters.
> This is because the struct modversion_info has the name member set to a
> size of MODULE_NAME_LEN. This is not the module name this is the symbol
> name so I'm guessing this is a mistake or at least a misused constant.
Yes, it's overloaded.
> Is it possible to increase this size to something more reasonable like
> 512 characters?
Oh, you almost had me. Almost.
This *looks* like the kind of naive question a newbie would ask. And a poor
coder would simply patch in the increase. A reasonable coder would also make
a comment about the potential bloat. A good coder would ask why you need
more than fifty_five_characters_in_one_single_exported_identifier.
But you're operating on a completely different level!
You chose this example to demonstrate, by (if I may) expandio ad absurdum,
that our current approach is flawed. Obviously you *knew* that it could be
converted to a pointer, and equally obviously this would require us to
process relocations before parsing version symbols. Clearly, you understood
that this would mean we had to find another solution for struct module
versioning, but you knew that that was always the first symbol version
You no-doubt knew that we could potentially save 7% on our module size using
this approach. But obviously not wanting to criticize my code, you instead
chose this oh-so-subtle intimation where I would believe the triumph to be
I am humbled by your genius, and I only hope that my patch series approaches
the Nirvanic perfection you foresaw.
Kudos Shawn, kudos!
to post comments)