[Buildroot] [PATCH 1/3] arch/config.in.arc: Introduce the ARC optimized hs38 config
Yann E. MORIN
yann.morin.1998 at free.fr
Mon Nov 11 21:09:00 UTC 2019
Vineet, All,
On 2019-11-11 18:47 +0000, Vineet Gupta spake thusly:
> On 11/9/19 5:46 AM, Thomas Petazzoni wrote:
> > On Fri, 8 Nov 2019 09:41:10 -0800
> > Vineet Gupta <Vineet.Gupta1 at synopsys.com> wrote:
> >> Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
> >> ---
> >> arch/Config.in.arc | 21 ++++++++++++++-------
> >> 1 file changed, 14 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/arch/Config.in.arc b/arch/Config.in.arc
> >> index c65bb01f1f4f..284951b82cee 100644
> >> --- a/arch/Config.in.arc
> >> +++ b/arch/Config.in.arc
> >> @@ -11,13 +11,19 @@ config BR2_arc750d
> >> config BR2_arc770d
> >> bool "ARC 770D"
> >>
> >> -config BR2_archs38
> >> +config BR2_archs
[Note this change, above ^^^]
> >> bool "ARC HS38"
> >> help
> >> Generic ARC HS capable of running Linux, i.e. with MMU,
> >> - caches and multiplier. Also it corresponds to the default
> >> + caches and 32-bit multiplier. Also it corresponds to the default
> >> configuration in older GNU toolchain versions.
> >>
> >> +config BR2_archs38
> >> + bool "ARC HS38 with 64-bit mpy"
[and note this, above^^^]
> > This re-use of an existing name is a bit annoying. Indeed, all existing
> > users of Buildroot that have a configuration with BR2_archs38 will now
> > be building for a ARC system with a 64-bit multiplier, while they were
> > previously building for a 32-bit multiplier.
> >
> > I see that what you have done is to try to be consistent between the
> > BR2_ options and the gcc options. I'm hesitating between keeping the
> > consistency but making the migration a bit annoying for users, or
> > breaking the consistency to make the migration smooth for users.
> >
> > Since I think the number of affected users will probably be quite
> > small/limited, I think I would be fine with merging your patch as-is,
> > but I'd like to hear from others.
>
> I agree that this might cause potential breakage, but this is not totally
> uncharted territory for software build config. We've been building Linux kernel
> with this option as default since mid 2018.
I think there is some misunderstanding.
What Thomas and I argue on, is the way to change the meaning for the
BR2_archs38 option.
Before this patch, BR2_archs38 meant "ARC HS38". But with your patch, it
now means "ARC HS38 with 64-bit mpy".
So, a user that updates their Buildroot configurationi which previously
had a "plain" HS38 setup, but with this patch, they get an "extended"
HS38 with the 64-bit multiplier.
That's why I suggested in my own reply, to keep BR2_archs38 as it was
before, and introduce BR2_archs38_64mpy to mean the new HS38 w/ the
64-bit multiplier.
Indeed, it does not match the gcc config options, but that would hardly
be the only derogation we have in Buildroot... ;-)
> 2018-09-07 00a99339f0a3 ARCv2: build: use mcpu=hs38 iso generic mcpu=archs
>
> Granted that kernel build is just one part of puzzle and any latent codegen issues
> are more likely to surface with default applied to full software stack, I would
> still vote for switching default to -mcpu=hs38
Changing the meaning of an option, and changing the default of a choice,
are two different things. I'm OK with changing the default, but I'd
rather that options keep their meaning.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list