From: gioh.kim@lge•com (Gioh Kim)
To: linux-arm-kernel@lists•infradead.org
Subject: ARM: mm: Could I change module space size or place modules in vmalloc area?
Date: Wed, 12 Mar 2014 15:38:39 +0900 [thread overview]
Message-ID: <000501cf3dbd$b49ac970$1dd05c50$@lge.com> (raw)
In-Reply-To: <201401031423.55336.arnd@arndb.de>
I am sorry to read your mail so late.
My module had been a proprietary driver so that I requested to strip it and
got small size driver.
Thank you for attention.
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Friday, January 03, 2014 10:24 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: Russell King - ARM Linux; HyoJun Im; linux-mm at kvack.org; Gioh Kim
> Subject: Re: ARM: mm: Could I change module space size or place modules in
> vmalloc area?
>
> On Friday 03 January 2014, Russell King - ARM Linux wrote:
> > On Fri, Jan 03, 2014 at 01:10:09PM +0100, Arnd Bergmann wrote:
> > > Aside from the good comments that Russell made, I would remark that
> > > the fact that you need multiple megabytes worth of modules indicates
> > > that you are doing something wrong. Can you point to a git tree
> > > containing those modules?
> >
> > From the comments which have been made, one point that seems to have
> > been identified is that if this module is first stripped and then
> > loaded, it can load, but if it's unstripped, it's too big. This
> > sounds suboptimal to me - the debug info shouldn't be loaded into the
> kernel.
>
> Reading the layout_and_allocate() function, that is probably the intention
> already, and if something goes wrong there on ARM, it could be fixed up in
> an arch specific module_frob_arch_sections() function.
>
> > However, I guess there's bad interactions with module signing if you
> > don't do this and the module was signed with the debug info present,
> > so I don't think there's a good solution for this.
>
> My point was another anyway: I can't think of any good reason why you
> would end up with this many modules on any sane system. The only cases
> I've seen so far are
>
> - modules written in C++, with libstdc++ linked into the module
> - a closed-source platform port hidden in a loadable module that
> contains all the device drivers and subsystems while ignoring the
> infrastructure we have in the kernel, and the possible legal
> implications.
> - a bug in the module using large arrays that should just be
> dynamically allocated.
> - device firmware statically linked into the module rather than
> loaded using request_firmware.
>
> In each of these cases, the real answer is to fix the code they are trying
> to load to do things in a more common way, especially if the intention is
> to eventually merge the code upstream. It is of course possible that they
> are indeed trying something valid, that's why I asked to see the source
> code.
>
> Arnd
prev parent reply other threads:[~2014-03-12 6:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-02 10:04 ARM: mm: Could I change module space size or place modules in vmalloc area? Gioh Kim
2014-01-02 10:13 ` Baruch Siach
2014-01-03 0:39 ` Gioh Kim
2014-01-03 0:47 ` Russell King - ARM Linux
2014-01-03 2:52 ` Gioh Kim
2014-04-26 2:12 ` Jianguo Wu
2014-04-29 11:19 ` Will Deacon
2014-04-29 11:35 ` Arnd Bergmann
2014-04-29 12:40 ` Will Deacon
2014-01-03 12:10 ` Arnd Bergmann
2014-01-03 12:22 ` Russell King - ARM Linux
2014-01-03 13:23 ` Arnd Bergmann
2014-03-12 6:38 ` Gioh Kim [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='000501cf3dbd$b49ac970$1dd05c50$@lge.com' \
--to=gioh.kim@lge$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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