public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: mkalikot@codeaurora.org
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Jeff Johnson <jjohnson@codeaurora.org>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Prasad Sodagudi <psodagud@quicinc.com>,
	Elliot Berman <eberman@quicinc.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Michal Marek <michal.lkml@markovi.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] kbuild: handle excessively long argument lists
Date: Tue, 19 Jan 2021 12:02:56 -0800	[thread overview]
Message-ID: <8ddd0f29e30684ce9fcd2dd19a104bd2@codeaurora.org> (raw)
In-Reply-To: <CAK7LNASLQWiSfY_iGs8hv8mo_yQaKXPpKo7u0BxPpANwkRatQA@mail.gmail.com>

On 2021-01-15 13:53, Masahiro Yamada wrote:
> On Sat, Jan 16, 2021 at 5:15 AM <jjohnson@codeaurora.org> wrote:
>> 
>> On 2021-01-14 17:12, Masahiro Yamada wrote:
>> > On Fri, Jan 15, 2021 at 6:50 AM Jeff Johnson <jjohnson@codeaurora.org>
>> > wrote:
>> >>
>> >> From: Mahesh Kumar Kalikot Veetil <mkalikot@codeaurora.org>
>> >>
>> >> Modules with a large number of compilation units may be
>> >> exceeding AR and LD command argument list. Handle this gracefully by
>> >> writing the long argument list in a file. The command line options
>> >> read from file are inserted in place of the original @file option.
>> >>
>> >> The usage is well documented at
>> >> https://www.gnu.org/software/make/manual/html_node/File-Function.html
>> >>
>> >> Signed-off-by: Mahesh Kumar Kalikot Veetil <mkalikot@codeaurora.org>
>> >> Signed-off-by: Jeff Johnson <jjohnson@codeaurora.org>
>> >> ---
>> >
>> >
>> >
>> >
>> > First, is this a real problem?
>> > If so, which module is exceeding the command line limit?
>> 
>> On 2021-01-14 17:12, Masahiro Yamada wrote:
>> > First, is this a real problem?
>> > If so, which module is exceeding the command line limit?
>> 
>> Mahesh & I appreciate all of the feedback.
>> 
>> The issue is seen in an Android environment with an out-of-tree
>> driver. The combination of long path names and a large number
>> of source files is leading to the issue.
>> 
>> Since Mahesh & I are not Kbuild gurus, is there an alternative
>> solution to this issue?
>> 
>> Jeff
> 
> 
> I see.
> 
> The support for out-of-tree modules
> is not nice in this regard, but fixing it
> would need many changes.
> 

Agree with that. I checked the same after your first comment on this 
thread.
It needs changes in multiple layers of makefiles.

> 
> The long-term solution might be to upstream your driver,
> but it might not be possible.
> 
> 
> 
> 
> 
> 
> One cheesy workaround might be to point the module path
> via a symbolic link.
> 
> 
> Let's say your module is located in a very deep
> directory,
> /home/foo/long/long/.../path/to/your/module
> 
> 
>  make M=/home/foo/long/long/.../path/to/your/module modules
> 
> would fail due to the too long command line.
> 
> 
> 
> 
> First, create a symbolic link as follows:
> 
>  ln -s /home/foo/long/long/.../path/to/your/module mod_dir
> 
> 
> Then, pass the symbolic link to M= option.
> 
>  make M=mod_dir modules

Thanks for the suggestion. Earlier, we have used a similar workaround
of using relative path instead of absolute to reduce the command line
length.


What's your input on the following approach where we link object
files in different stages to reduce the command line length.


./Makefile

  # foo.c is combined and final module.

  obj-m = fooa.o foob.o fooc.o

  # link already combined object files
  fooc-y := fooa.o foob.o

  # combine into different groups
  fooa-y := foo1.o foo2.o
  foob-y := foo3.o foo4.o

  ....


Note: We need to add MODULE_LICENSE in every group.


make -C ../linux-kbuild M=/local/mnt2/workspace/dev/foo modules

   CC [M]  /local/mnt2/workspace/dev/foo/foo1.o
   CC [M]  /local/mnt2/workspace/dev/foo/foo2.o
   LD [M]  /local/mnt2/workspace/dev/foo/fooa.o
   CC [M]  /local/mnt2/workspace/dev/foo/foo3.o
   CC [M]  /local/mnt2/workspace/dev/foo/foo4.o
   LD [M]  /local/mnt2/workspace/dev/foo/foob.o
   LD [M]  /local/mnt2/workspace/dev/foo/fooc.o
   MODPOST /local/mnt2/workspace/dev/foo/Module.symvers
   CC [M]  /local/mnt2/workspace/dev/foo/fooa.mod.o
   LD [M]  /local/mnt2/workspace/dev/foo/fooa.ko
   CC [M]  /local/mnt2/workspace/dev/foo/foob.mod.o
   LD [M]  /local/mnt2/workspace/dev/foo/foob.ko
   CC [M]  /local/mnt2/workspace/dev/foo/fooc.mod.o
   LD [M]  /local/mnt2/workspace/dev/foo/fooc.ko



  reply	other threads:[~2021-01-19 20:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-13  1:18 [PATCH 1/2] kbuild: simplify cmd_mod Jeff Johnson
2021-01-13  1:18 ` [PATCH 2/2] kbuild: handle excessively long argument lists Jeff Johnson
2021-01-14 21:07   ` Nick Desaulniers
2021-01-14 21:32     ` jjohnson
2021-01-14 21:49   ` [PATCH v2 " Jeff Johnson
2021-01-15  1:00     ` Nick Desaulniers
2021-01-15  1:25       ` Masahiro Yamada
2021-01-15  1:12     ` Masahiro Yamada
2021-01-15 20:15       ` jjohnson
2021-01-15 21:53         ` Masahiro Yamada
2021-01-19 20:02           ` mkalikot [this message]
2021-01-15  1:07 ` [PATCH 1/2] kbuild: simplify cmd_mod Nick Desaulniers

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=8ddd0f29e30684ce9fcd2dd19a104bd2@codeaurora.org \
    --to=mkalikot@codeaurora.org \
    --cc=eberman@quicinc.com \
    --cc=jjohnson@codeaurora.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=ndesaulniers@google.com \
    --cc=psodagud@quicinc.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