All of lore.kernel.org
 help / color / mirror / Atom feed
From: sam@ravnborg.org (Sam Ravnborg)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64/crypto: fix makefile rule for aes-glue-%.o
Date: Thu, 24 Jul 2014 22:45:26 +0200	[thread overview]
Message-ID: <20140724204526.GA11754@ravnborg.org> (raw)
In-Reply-To: <CAKv+Gu8ikMGNVHeuujSf4eaK+LOFKMWxKF8i76VthnKYgvOcYQ@mail.gmail.com>

On Thu, Jul 24, 2014 at 09:25:13PM +0200, Ard Biesheuvel wrote:
> On 24 July 2014 18:12, Sam Ravnborg <sam@ravnborg.org> wrote:
> > On Thu, Jul 24, 2014 at 04:24:48PM +0200, Ard Biesheuvel wrote:
> >> On 24 July 2014 16:18, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >> > On 24 July 2014 15:40, Andreas Schwab <schwab@suse.de> wrote:
> >> >> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
> >> >>
> >> >>> On 24 July 2014 15:26, Andreas Schwab <schwab@suse.de> wrote:
> >> >>>> You are not using CONFIG_MODVERSIONS.
> >> >>>>
> >> >>>
> >> >>> I am
> >> >>
> >> >> No, you aren't, since you say that your .cmd contains a command to
> >> >> create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't.
> >> >>
> >> >
> >> > OK, you're right, it contains a command to create .tmp_aes-glue-ce.o.
> >> > But I am still not seeing the error you are seeing, strangely enough.
> >>
> >> OK, now I am seeing it.
> >>
> >> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >
> > Jumping in the end of the thread here - sorry for that.
> >
> 
> No worries
> 
> > Another way to solve this would be to create two
> > small wrapper files:
> > aes-glue-neon.c - which include aes-glue.c
> > aes-glue-ce.c that include aes-glue.c
> >
> > Then you could use standard kbuild support for building your module.
> > And we will not potentially break it when we change cc_o_c in the near future.
> >
> 
> I see how that would fix this issue, but frankly, if we need to add .c
> files that only #include other .c files to support building multiple
> objects from a single .c file, I think the flaw is in the build
> system, and I would rather fix the build system instead.
The kbuild syntax could be extended to allow building multiple .o files from
a single .c file. But the need for this feature is so seldom that
people would not recognize the syntax most likely.

Btw. the current solution is already faulty - even with the fix.
There are no support for make C=2 arch/.../crypto/

Therefore - for now the correct fix is to use two wrapper .c files,
and accept this. It will not have the C=2 problem above.

	Sam

WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Andreas Schwab <schwab@suse.de>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] arm64/crypto: fix makefile rule for aes-glue-%.o
Date: Thu, 24 Jul 2014 22:45:26 +0200	[thread overview]
Message-ID: <20140724204526.GA11754@ravnborg.org> (raw)
In-Reply-To: <CAKv+Gu8ikMGNVHeuujSf4eaK+LOFKMWxKF8i76VthnKYgvOcYQ@mail.gmail.com>

On Thu, Jul 24, 2014 at 09:25:13PM +0200, Ard Biesheuvel wrote:
> On 24 July 2014 18:12, Sam Ravnborg <sam@ravnborg.org> wrote:
> > On Thu, Jul 24, 2014 at 04:24:48PM +0200, Ard Biesheuvel wrote:
> >> On 24 July 2014 16:18, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >> > On 24 July 2014 15:40, Andreas Schwab <schwab@suse.de> wrote:
> >> >> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
> >> >>
> >> >>> On 24 July 2014 15:26, Andreas Schwab <schwab@suse.de> wrote:
> >> >>>> You are not using CONFIG_MODVERSIONS.
> >> >>>>
> >> >>>
> >> >>> I am
> >> >>
> >> >> No, you aren't, since you say that your .cmd contains a command to
> >> >> create aes-glue-ce.o, which with CONFIG_MODVERSIONS it doesn't.
> >> >>
> >> >
> >> > OK, you're right, it contains a command to create .tmp_aes-glue-ce.o.
> >> > But I am still not seeing the error you are seeing, strangely enough.
> >>
> >> OK, now I am seeing it.
> >>
> >> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >
> > Jumping in the end of the thread here - sorry for that.
> >
> 
> No worries
> 
> > Another way to solve this would be to create two
> > small wrapper files:
> > aes-glue-neon.c - which include aes-glue.c
> > aes-glue-ce.c that include aes-glue.c
> >
> > Then you could use standard kbuild support for building your module.
> > And we will not potentially break it when we change cc_o_c in the near future.
> >
> 
> I see how that would fix this issue, but frankly, if we need to add .c
> files that only #include other .c files to support building multiple
> objects from a single .c file, I think the flaw is in the build
> system, and I would rather fix the build system instead.
The kbuild syntax could be extended to allow building multiple .o files from
a single .c file. But the need for this feature is so seldom that
people would not recognize the syntax most likely.

Btw. the current solution is already faulty - even with the fix.
There are no support for make C=2 arch/.../crypto/

Therefore - for now the correct fix is to use two wrapper .c files,
and accept this. It will not have the C=2 problem above.

	Sam

  reply	other threads:[~2014-07-24 20:45 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-30 13:14 [PATCH] arm64/crypto: fix makefile rule for aes-glue-%.o Andreas Schwab
2014-06-30 13:14 ` Andreas Schwab
2014-06-30 13:38 ` Ard Biesheuvel
2014-06-30 13:38   ` Ard Biesheuvel
2014-06-30 13:56   ` Andreas Schwab
2014-06-30 13:56     ` Andreas Schwab
2014-06-30 14:08     ` Ard Biesheuvel
2014-06-30 14:08       ` Ard Biesheuvel
2014-07-24 12:29       ` Andreas Schwab
2014-07-24 12:29         ` Andreas Schwab
2014-07-24 12:35         ` Ard Biesheuvel
2014-07-24 12:35           ` Ard Biesheuvel
2014-07-24 12:53           ` Ard Biesheuvel
2014-07-24 12:53             ` Ard Biesheuvel
2014-07-24 13:26             ` Andreas Schwab
2014-07-24 13:26               ` Andreas Schwab
2014-07-24 13:29               ` Ard Biesheuvel
2014-07-24 13:29                 ` Ard Biesheuvel
2014-07-24 13:40                 ` Andreas Schwab
2014-07-24 13:40                   ` Andreas Schwab
2014-07-24 14:18                   ` Ard Biesheuvel
2014-07-24 14:18                     ` Ard Biesheuvel
2014-07-24 14:24                     ` Ard Biesheuvel
2014-07-24 14:24                       ` Ard Biesheuvel
2014-07-24 16:12                       ` Sam Ravnborg
2014-07-24 16:12                         ` Sam Ravnborg
2014-07-24 19:25                         ` Ard Biesheuvel
2014-07-24 19:25                           ` Ard Biesheuvel
2014-07-24 20:45                           ` Sam Ravnborg [this message]
2014-07-24 20:45                             ` Sam Ravnborg
2014-07-25  6:28                             ` Ard Biesheuvel
2014-07-25  6:28                               ` Ard Biesheuvel
2014-07-27 18:40                               ` Sam Ravnborg
2014-07-27 18:40                                 ` Sam Ravnborg
2014-07-28 17:00                                 ` Ard Biesheuvel
2014-07-28 17:00                                   ` Ard Biesheuvel
2014-07-28 19:06                                   ` Sam Ravnborg
2014-07-28 19:06                                     ` Sam Ravnborg
  -- strict thread matches above, loose matches on Subject: below --
2014-07-24 16:03 Ard Biesheuvel
2014-07-24 16:47 ` Catalin Marinas

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=20140724204526.GA11754@ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.