From: gregkh@linuxfoundation.org (Greg KH)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] binder: let ANDROID_BINDER_IPC_32BIT be selectable on 32bit ARM
Date: Tue, 22 Aug 2017 22:37:00 -0700 [thread overview]
Message-ID: <20170823053700.GC23426@kroah.com> (raw)
In-Reply-To: <CALAqxLV50xNE8nBF4kfEgA3-OMUP=GYdh7DPJfYnxNjEszZD0Q@mail.gmail.com>
On Tue, Aug 22, 2017 at 08:14:10PM -0700, John Stultz wrote:
> On Tue, Aug 22, 2017 at 8:01 PM, Jisheng Zhang <jszhang@marvell.com> wrote:
> > On Tue, 22 Aug 2017 19:57:04 -0700 John Stultz wrote:
> >
> >> On Tue, Aug 22, 2017 at 7:56 PM, John Stultz <john.stultz@linaro.org> wrote:
> >> > On Tue, Aug 22, 2017 at 7:34 PM, Jisheng Zhang <jszhang@marvell.com> wrote:
> >> >> On Tue, 22 Aug 2017 18:51:08 -0700 Greg KH wrote:
> >> >>
> >> >>> On Tue, Aug 08, 2017 at 07:03:05PM +0800, Jisheng Zhang wrote:
> >> >>> > As noted in commit d0bdff0db809 ("staging: Fix build issues with new
> >> >>> > binder API"), we can add back the choice for 32bit ARM "once a 64bit
> >> >>> > __get_user_asm_* implementation is merged." Commit e38361d032f1 ("ARM:
> >> >>> > 8091/2: add get_user() support for 8 byte types") has added the
> >> >>> > support, so it's time to let ANDROID_BINDER_IPC_32BIT be selectable on
> >> >>> > 32bit ARM
> >> >>>
> >> >>> Ok, but:
> >> >>>
> >> >>> >
> >> >>> > Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
> >> >>> > ---
> >> >>> > drivers/android/Kconfig | 2 +-
> >> >>> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >>> >
> >> >>> > diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
> >> >>> > index 832e885349b1..aca5dc30b97b 100644
> >> >>> > --- a/drivers/android/Kconfig
> >> >>> > +++ b/drivers/android/Kconfig
> >> >>> > @@ -32,7 +32,7 @@ config ANDROID_BINDER_DEVICES
> >> >>> > therefore logically separated from the other devices.
> >> >>> >
> >> >>> > config ANDROID_BINDER_IPC_32BIT
> >> >>> > - bool
> >> >>> > + bool "Use old (Android 4.4 and earlier) 32-bit binder API"
> >> >>> > depends on !64BIT && ANDROID_BINDER_IPC
> >> >>>
> >> >>> You don't actually change the depends line :(
> >> >>>
> >> >>> Please fix up, and test it, and then resend.
> >> >>
> >> >> IHOM, the dependency is correct: 64bit platforms don't support
> >> >> ANDROID_BINDER_IPC_32BIT. What do you think?
> >> >
> >> > I think this indicates the commit message is unclear.
> >> >
> >> > Part of it is that the config is inverted from the description. The
> >> > patch doesn't enable the 32bit legacy binder ABI on 32bit systems, it
> >> > just allows the option to be unselected, so that the 64bit ABI will be
> >> > used on 32bit systems.
> >> >
> >> > Conceptually I don't have an objection to the change (though maybe try
> >> > to rework the commit message), but I don't have anything to actually
> >> > test it on right now, so I'm hesitant to ack it.
> >>
> >> It might also be good to add some detail as to the motivation for this
> >> change? What benefit does it bring to 32bit platforms to use the newer
> >> 64bit ABI?
> >>
> >
> > To be honest, the motivation is just to add one more choice for 32bit
> > platform and let the code be tested under 32bit platform. Maybe we
> > could then remove ANDROID_BINDER_IPC_32BIT and the related code after
> > some time?
>
> I'm mixed. It would be nice to deprecate the old 32bit ABI, but binder
> is a real Linux kernel interface now, so we don't break compatibility
> (at least if it affects anyone - which may be questionable here - not
> sure there's many upstream 32bit platforms concerned with running
> legacy Android builds). But just adding the extra option just means
> there's yet another configuration to test and to keep working. So you
> may want to articulate the benefits better to make this worth the
> effort of doing a full transition.
Future versions of Android "might" be changing if they support, or not,
all of the different combinations of 32/64 bit apis. So maybe we should
wait until a real solid direction with regards to this is published
before worrying about dropping anything...
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: John Stultz <john.stultz@linaro.org>
Cc: "Jisheng Zhang" <jszhang@marvell.com>,
devel@driverdev.osuosl.org,
"Riley Andrews" <riandrews@android.com>,
lkml <linux-kernel@vger.kernel.org>,
"Arve Hjønnevåg" <arve@android.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] binder: let ANDROID_BINDER_IPC_32BIT be selectable on 32bit ARM
Date: Tue, 22 Aug 2017 22:37:00 -0700 [thread overview]
Message-ID: <20170823053700.GC23426@kroah.com> (raw)
In-Reply-To: <CALAqxLV50xNE8nBF4kfEgA3-OMUP=GYdh7DPJfYnxNjEszZD0Q@mail.gmail.com>
On Tue, Aug 22, 2017 at 08:14:10PM -0700, John Stultz wrote:
> On Tue, Aug 22, 2017 at 8:01 PM, Jisheng Zhang <jszhang@marvell.com> wrote:
> > On Tue, 22 Aug 2017 19:57:04 -0700 John Stultz wrote:
> >
> >> On Tue, Aug 22, 2017 at 7:56 PM, John Stultz <john.stultz@linaro.org> wrote:
> >> > On Tue, Aug 22, 2017 at 7:34 PM, Jisheng Zhang <jszhang@marvell.com> wrote:
> >> >> On Tue, 22 Aug 2017 18:51:08 -0700 Greg KH wrote:
> >> >>
> >> >>> On Tue, Aug 08, 2017 at 07:03:05PM +0800, Jisheng Zhang wrote:
> >> >>> > As noted in commit d0bdff0db809 ("staging: Fix build issues with new
> >> >>> > binder API"), we can add back the choice for 32bit ARM "once a 64bit
> >> >>> > __get_user_asm_* implementation is merged." Commit e38361d032f1 ("ARM:
> >> >>> > 8091/2: add get_user() support for 8 byte types") has added the
> >> >>> > support, so it's time to let ANDROID_BINDER_IPC_32BIT be selectable on
> >> >>> > 32bit ARM
> >> >>>
> >> >>> Ok, but:
> >> >>>
> >> >>> >
> >> >>> > Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
> >> >>> > ---
> >> >>> > drivers/android/Kconfig | 2 +-
> >> >>> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >>> >
> >> >>> > diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
> >> >>> > index 832e885349b1..aca5dc30b97b 100644
> >> >>> > --- a/drivers/android/Kconfig
> >> >>> > +++ b/drivers/android/Kconfig
> >> >>> > @@ -32,7 +32,7 @@ config ANDROID_BINDER_DEVICES
> >> >>> > therefore logically separated from the other devices.
> >> >>> >
> >> >>> > config ANDROID_BINDER_IPC_32BIT
> >> >>> > - bool
> >> >>> > + bool "Use old (Android 4.4 and earlier) 32-bit binder API"
> >> >>> > depends on !64BIT && ANDROID_BINDER_IPC
> >> >>>
> >> >>> You don't actually change the depends line :(
> >> >>>
> >> >>> Please fix up, and test it, and then resend.
> >> >>
> >> >> IHOM, the dependency is correct: 64bit platforms don't support
> >> >> ANDROID_BINDER_IPC_32BIT. What do you think?
> >> >
> >> > I think this indicates the commit message is unclear.
> >> >
> >> > Part of it is that the config is inverted from the description. The
> >> > patch doesn't enable the 32bit legacy binder ABI on 32bit systems, it
> >> > just allows the option to be unselected, so that the 64bit ABI will be
> >> > used on 32bit systems.
> >> >
> >> > Conceptually I don't have an objection to the change (though maybe try
> >> > to rework the commit message), but I don't have anything to actually
> >> > test it on right now, so I'm hesitant to ack it.
> >>
> >> It might also be good to add some detail as to the motivation for this
> >> change? What benefit does it bring to 32bit platforms to use the newer
> >> 64bit ABI?
> >>
> >
> > To be honest, the motivation is just to add one more choice for 32bit
> > platform and let the code be tested under 32bit platform. Maybe we
> > could then remove ANDROID_BINDER_IPC_32BIT and the related code after
> > some time?
>
> I'm mixed. It would be nice to deprecate the old 32bit ABI, but binder
> is a real Linux kernel interface now, so we don't break compatibility
> (at least if it affects anyone - which may be questionable here - not
> sure there's many upstream 32bit platforms concerned with running
> legacy Android builds). But just adding the extra option just means
> there's yet another configuration to test and to keep working. So you
> may want to articulate the benefits better to make this worth the
> effort of doing a full transition.
Future versions of Android "might" be changing if they support, or not,
all of the different combinations of 32/64 bit apis. So maybe we should
wait until a real solid direction with regards to this is published
before worrying about dropping anything...
thanks,
greg k-h
next prev parent reply other threads:[~2017-08-23 5:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-08 11:03 [PATCH] binder: let ANDROID_BINDER_IPC_32BIT be selectable on 32bit ARM Jisheng Zhang
2017-08-08 11:03 ` Jisheng Zhang
2017-08-23 1:51 ` Greg KH
2017-08-23 1:51 ` Greg KH
2017-08-23 2:34 ` Jisheng Zhang
2017-08-23 2:34 ` Jisheng Zhang
2017-08-23 2:56 ` John Stultz
2017-08-23 2:56 ` John Stultz
2017-08-23 2:56 ` [EXT] " Jisheng Zhang
2017-08-23 2:56 ` Jisheng Zhang
2017-08-23 2:57 ` John Stultz
2017-08-23 2:57 ` John Stultz
2017-08-23 3:01 ` Jisheng Zhang
2017-08-23 3:01 ` Jisheng Zhang
2017-08-23 3:14 ` John Stultz
2017-08-23 3:14 ` John Stultz
2017-08-23 5:37 ` Greg KH [this message]
2017-08-23 5:37 ` Greg KH
2017-08-23 18:48 ` Rob Herring
2017-08-23 18:48 ` Rob Herring
2017-08-24 1:44 ` Jisheng Zhang
2017-08-24 1:44 ` Jisheng Zhang
2017-08-23 5:35 ` Greg KH
2017-08-23 5:35 ` Greg KH
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=20170823053700.GC23426@kroah.com \
--to=gregkh@linuxfoundation.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.