From: Rusty Russell <rusty@rustcorp.com.au>
To: Shawn Bohrer <shawn.bohrer@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Modversions and long symbol names
Date: Wed, 28 Jan 2009 23:38:56 +1030 [thread overview]
Message-ID: <200901282338.56696.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20090120173636.GB24529@mediacenter>
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 anyway.
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 mine alone!
I am humbled by your genius, and I only hope that my patch series approaches the Nirvanic perfection you foresaw.
Kudos Shawn, kudos!
Rusty.
prev parent reply other threads:[~2009-01-28 13:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-20 17:36 Modversions and long symbol names Shawn Bohrer
2009-01-27 23:13 ` Shawn Bohrer
2009-01-28 13:08 ` Rusty Russell [this message]
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=200901282338.56696.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=shawn.bohrer@gmail.com \
/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