[Buildroot] [PATCH v2 1/1] erlang: remove non-SMP build option
Yann E. MORIN
yann.morin.1998 at free.fr
Wed Dec 20 13:28:12 UTC 2017
Thomas, Frank, All,
On 2017-12-20 11:26 +0100, Thomas Petazzoni spake thusly:
> On Tue, 19 Dec 2017 13:45:44 -0500, Frank Hunleth wrote:
> > The non-SMP scheduler was deprecated with the Erlang/OTP 20.0 release and
> > slated for removal with the next major Erlang release. Since the non-SMP
> > scheduler isn't even built anymore, this option no longer has the
> > intended effect of saving space or compile time. The SMP scheduler
> > supports both SMP and non-SMP processors, so removing the option will
> > not break any platforms.
> >
> > Signed-off-by: Frank Hunleth <fhunleth at troodon-software.com>
> > ---
> > Changes v1 -> v2:
> > - Added text to Config.in.legacy to explain the removal of the option
> > (suggested by Yann - I added to Config.in.legacy after thinking about
> > it, since anyone who previously selected this option may be surprised
> > to see the SMP scheduler in their process list.)
> >
> > Config.in.legacy | 10 ++++++++++
> > package/erlang/Config.in | 10 ----------
> > package/erlang/erlang.mk | 4 ----
> > 3 files changed, 10 insertions(+), 14 deletions(-)
> >
> > diff --git a/Config.in.legacy b/Config.in.legacy
> > index decbace..1607df6 100644
> > --- a/Config.in.legacy
> > +++ b/Config.in.legacy
> > @@ -153,6 +153,16 @@ config BR2_PACKAGE_GNUPG2_GPGV2
> > The gpgv2 executable is now named gpgv. The config option
> > has been renamed accordingly.
> >
> > +config BR2_PACKAGE_ERLANG_SMP
> > + bool "erlang smp option removed"
> > + select BR2_LEGACY
> > + help
> > + This option used to disable Erlang's SMP scheduler to save
> > + space. Since Erlang 20.0 deprecated the non-SMP scheduler and
> > + no longer builds it, it is no longer relevant. See the Erlang
> > + 20.0 release notes for more information. Note that the SMP
> > + scheduler runs on both SMP and non-SMP CPUs.
>
> As Yann explained, we do not want a Config.in.legacy option. Indeed,
> the new behavior is identical to having the option enabled, so there is
> no point in having a Config.in.legacy entry.
Yes, indeed.
Frank, what I meant was that, usually we have to add a legacy entry to
tell users what is happenning. However, in this particular case, it is
not needed because a build with this option enabled previously will now
yield the same result as build now with this option removed.
But this it is usualy to add a legacy entry, for the reviewr's sake, it
is important that the commit log explains why a legacy entry is not
needed.
Sorry if I was not explicit enough about this...
Regards,
Yann E. MORIN.
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list