From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Arnd Bergmann <arnd@arndb.de>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Darren Hart (VMware)" <dvhart@infradead.org>,
Mattias Jacobsson <2pi@mok.nu>, Jeff Mahoney <jeffm@suse.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mod_devicetable.h: reduce sizeof(struct of_device_id) by 80 bytes
Date: Thu, 2 May 2019 11:41:28 +0200 [thread overview]
Message-ID: <73918e46-e3c8-edc4-c941-e650c05519c8@rasmusvillemoes.dk> (raw)
In-Reply-To: <CAK8P3a1Fu64YhQzvSEy8j3oZ3XwUN81fY+K6Z6ksHhqDWzbxNA@mail.gmail.com>
On 26/04/2019 11.27, Arnd Bergmann wrote:
> On Thu, Apr 25, 2019 at 10:31 PM Rasmus Villemoes
> <linux@rasmusvillemoes.dk> wrote:
>>
>> For an arm imx_v6_v7_defconfig kernel, .rodata becomes 70K smaller;
>> .init.data shrinks by another ~13K, making the whole kernel image
>> about 83K, or 0.3%, smaller.
>>
>> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>
> The space savings are nice, but I wonder if the format of these
> structures is part of the ABI or not. I have some vague recollection
> of that, but it's possible that it's no longer true in this century.
>
> scripts/mod/file2alias.c processes the structures into a different
> format and seems to be written specifically to avoid problems
> with changes like the one you did. Can anyone confirm that
> this is true before we apply the patch?
I can't confirm it, of course, but I did do some digging around and
couldn't find anything other than file2alias, which as you mention is
prepared for such a change. I also couldn't find any specific reason for
the 128 (it's not a #define, so at least originally it didn't seem to be
tied to some external consumer) - Jeff, do you remember why you chose
that back when you did 5e6557722e69?
But we cannot really know whether there is some userspace tool that
parses the .ko ELF objects the same way that file2alias does, doing
pattern matching on the symbol names etc. I cannot see why anybody would
_do_ that (the in-tree infrastructure already generates the
MODULE_ALIAS() from which modules.alias gets generated), but the only
way of knowing, I think, is to try to apply the patch and see if anybody
complains.
Rasmus
next prev parent reply other threads:[~2019-05-02 9:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-25 20:31 Rasmus Villemoes
2019-04-26 9:27 ` Arnd Bergmann
2019-05-02 9:41 ` Rasmus Villemoes [this message]
2019-05-02 12:29 ` Jeff Mahoney
2019-05-02 13:07 ` Rasmus Villemoes
2019-04-26 11:05 ` Enrico Weigelt, metux IT consult
2019-04-26 11:33 ` Rasmus Villemoes
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=73918e46-e3c8-edc4-c941-e650c05519c8@rasmusvillemoes.dk \
--to=linux@rasmusvillemoes.dk \
--cc=2pi@mok.nu \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=dvhart@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=jeffm@suse.com \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®