All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masahiro Yamada <yamada.masahiro@socionext.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Nicolas Dichtel <nicolas.dichtel@6wind.com>
Subject: Re: linux-next: manual merge of the crypto tree with the kbuild tree
Date: Tue, 11 Apr 2017 16:00:45 +0900	[thread overview]
Message-ID: <CAK7LNASesrB5bEvFGxO_BbnqA-h0+TCxMQsmtbv3zqS7gNMe1Q@mail.gmail.com> (raw)
In-Reply-To: <20170411064009.GA11311@gondor.apana.org.au>

Hi Herbert,


2017-04-11 15:40 GMT+09:00 Herbert Xu <herbert@gondor.apana.org.au>:
> On Tue, Apr 11, 2017 at 03:34:43PM +0900, Masahiro Yamada wrote:
>> Hi Herbert,
>>
>>
>> 2017-04-11 14:12 GMT+09:00 Herbert Xu <herbert@gondor.apana.org.au>:
>> > On Tue, Apr 11, 2017 at 03:02:50PM +1000, Stephen Rothwell wrote:
>> >>
>> >> So basically we need CRYPTO_MAX_ALG_NAME to be 64 in the exported
>> >> header but 128 in the kernel header?  In which case the kbuild patch
>> >> needs to be changed not removed.  Or the merge resolution needs to be
>> >> cleverer.
>> >
>> > Actually the kbuild patch just needs to be reverted.  We should
>> > not export CRYPTO_MAX_ALG_NAME at all.  Each user-space interface
>> > that uses it already has its own limit and should not refer to the
>> > in-kernel value.
>>
>> CRYPTO_MAX_ALG_NAME is referenced from
>> include/uapi/linux/cryptouser.h
>>
>> If you exporting CRYPTO_MAX_ALG_NAME is wrong,
>> please move cryptouser.h out of the include/uapi directory.
>
> It doesn't reference it anymore in the latest cryptodev tree.
>
> So please revert the patch from the kbuild tree.
>

Ah, right.

Commit 4473710df1f8 fixed the problem,
but reverting the patch in kbuild will break the bisect'ability
of the kbuild tree.


I will consult people about how to handle this case.



-- 
Best Regards
Masahiro Yamada

  reply	other threads:[~2017-04-11  7:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-11  0:21 linux-next: manual merge of the crypto tree with the kbuild tree Stephen Rothwell
2017-04-11  2:42 ` Herbert Xu
2017-04-11  5:02   ` Stephen Rothwell
2017-04-11  5:12     ` Herbert Xu
2017-04-11  6:34       ` Masahiro Yamada
2017-04-11  6:40         ` Herbert Xu
2017-04-11  7:00           ` Masahiro Yamada [this message]
2017-04-11  7:19             ` Herbert Xu
2017-04-11  7:51     ` Masahiro Yamada
2017-04-11  9:22       ` Herbert Xu

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=CAK7LNASesrB5bEvFGxO_BbnqA-h0+TCxMQsmtbv3zqS7gNMe1Q@mail.gmail.com \
    --to=yamada.masahiro@socionext.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.com \
    --cc=sfr@canb.auug.org.au \
    /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.