erlang: remove non-SMP build option
PATCH v2 1/1 erlang: remove non-SMP build option
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.
---
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(-)
Config.in.legacy +10 -0
@@ -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. + ############################################################################### comment "Legacy options removed in 2017.11"
package/erlang/Config.in +0 -10
@@ -27,16 +27,6 @@ config BR2_PACKAGE_ERLANG if BR2_PACKAGE_ERLANG -config BR2_PACKAGE_ERLANG_SMP - bool "enable SMP support" - help - Erlang provides both a UP and an SMP emulator. The UP - emulator is always built, and this option enables - compilation of the SMP emulator. The choice of which - emulator to use is made at runtime. If you do not need SMP - support, turning this option off reduces compile time and - the size of the Erlang installation. - config BR2_PACKAGE_ERLANG_MEGACO bool "install megaco application" help
package/erlang/erlang.mk +0 -4
@@ -74,10 +74,6 @@ ERLANG_CONF_OPTS += --enable-shared-zlib ERLANG_DEPENDENCIES += zlib endif -ifeq ($(BR2_PACKAGE_ERLANG_SMP),) -ERLANG_CONF_OPTS += --disable-smp-support -endif - # Remove source, example, gs and wx files from staging and target. ERLANG_REMOVE_PACKAGES = gs wx
--
2.7.4
PATCH v2 1/1 erlang: remove non-SMP build option
Hello,
Quoted 27 lines · Frank Hunleth
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 <[email protected]>---
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(-)Config.in.legacy +0
-0@@ -153,6 +153,16 @@ config BR2_PACKAGE_GNUPG2_GPGV2 The gpgv2 executable is now named gpgv. The config option has been renamed accordingly.
Config.in.legacy config BR2_PACKAGE_GNUPG2_GPGV2 · line 164
Quoted 10 lines
Config.in.legacy +9
-0+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.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH v2 1/1 erlang: remove non-SMP build option
Thomas, Frank, All,
On 2017-12-20 11:26 +0100, Thomas Petazzoni spake thusly:
Quoted 29 lines · Frank Hunleth
Quoted 28 lines
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 <[email protected]>---
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(-)Config.in.legacy +0
-0@@ -153,6 +153,16 @@ config BR2_PACKAGE_GNUPG2_GPGV2 The gpgv2 executable is now named gpgv. The config option has been renamed accordingly.
Quoted 13 lines
Config.in.legacy config BR2_PACKAGE_GNUPG2_GPGV2 · line 164
Quoted 9 lines
Config.in.legacy +9
-0+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.
Quoted 11 lines
Best regards,
Thomas
Signature · 7 lines
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
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH v2 1/1 erlang: remove non-SMP build option
Hi all,
Quoted 46 lines · Yann E. MORIN
Thomas, Frank, All,
On 2017-12-20 11:26 +0100, Thomas Petazzoni spake thusly:
Quoted 29 lines · Frank Hunleth
Quoted 28 lines
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 <[email protected]>---
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(-)Config.in.legacy +0
-0@@ -153,6 +153,16 @@ config BR2_PACKAGE_GNUPG2_GPGV2 The gpgv2 executable is now named gpgv. The config option has been renamed accordingly.Quoted 13 lines
Config.in.legacy config BR2_PACKAGE_GNUPG2_GPGV2 · line 164
Quoted 9 lines
Config.in.legacy +9
-0+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.
Quoted 6 lines
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.
That's not true. Before if you enabled the option, you'd get the uniprocessor scheduler. With the change, you get the SMP scheduler.
In the .mk file, if you were to enable BR2_PACKAGE_ERLANG_SMP, that would pass "--disable-smp-support" to the configure script. That forces the uniprocessor scheduler. With this patch, you only can get the SMP scheduler. I'm not sure how many people would do this, but operationally, you'd see a process called "beam.smp" running on your system now. The uniprocessor scheduler made a process called "beam". That seems like a different result to me?
Looking over the Erlang release notes, the situation may even be worse now since they've added a --enable-plain-scheduler option to build the uniprocessor scheduler, so the current option BR2_PACKAGE_ERLANG_SMP option may not even work. I don't know, but the uniprocessor scheduler is not worth spending time on any more since it's going to be removed soon.
Quoted 4 lines
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.
I'm fine either way. I'm stuck in the thinking that this change isn't identical to the previous behavior, so I'm not sure how to explain it in the commit message. If someone indulges me with text, I'll gladly send a v3 or feel free to merge one of my other versions.
Frank
Quoted 25 lines
Sorry if I was not explicit enough about this...
Regards,
Yann E. MORIN.Quoted 11 lines
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. |'------------------------------^-------^------------------^--------------------'
PATCH v2 1/1 erlang: remove non-SMP build option
Frank, All,
On 2017-12-20 08:52 -0500, Frank Hunleth spake thusly:
Quoted 52 lines · Yann E. MORIN
Quoted 44 lines
On 2017-12-20 11:26 +0100, Thomas Petazzoni spake thusly:
Quoted 29 lines · Frank Hunleth
Quoted 28 lines
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 <[email protected]>---
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(-)Config.in.legacy +0
-0@@ -153,6 +153,16 @@ config BR2_PACKAGE_GNUPG2_GPGV2 The gpgv2 executable is now named gpgv. The config option has been renamed accordingly.Quoted 13 lines
Config.in.legacy config BR2_PACKAGE_GNUPG2_GPGV2 · line 164
Quoted 9 lines
Config.in.legacy +9
-0+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.
Quoted 6 lines
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.
Quoted 5 lines
That's not true. Before if you enabled the option, you'd get the uniprocessor scheduler. With the change, you get the SMP scheduler.
In the .mk file, if you were to enable
BR2_PACKAGE_ERLANG_SMP, that would pass "--disable-smp-support" to the configure script.
That's wrong, because the code was:
ifeq ($(BR2_PACKAGE_ERLANG_SMP),)
ERLANG_CONF_OPTS += --disable-smp-support
endifIf BR2_PACKAGE_ERLANG_SMP was set, it would not fulfill the condition, and we would *not* pass --disable-smp-support. But if it was unset, then the condition would be true, and we'd pass --disable-smp-support.
Now, with your change, we will no longer pass --disable-smp-support, ever, so this is back to option enabled.
(note that we can't account for the case where the option was disabled; that's a limitation, but we don't really care).
Quoted 7 lines
That
forces the uniprocessor scheduler. With this patch, you only can get the SMP scheduler. I'm not sure how many people would do this, but operationally, you'd see a process called "beam.smp" running on your system now. The uniprocessor scheduler made a process called "beam". That seems like a different result to me?
Quoted 6 lines
Looking over the Erlang release notes, the situation may even be worse now since they've added a --enable-plain-scheduler option to build the uniprocessor scheduler, so the current option
BR2_PACKAGE_ERLANG_SMPoption may not even work. I don't know, but the uniprocessor scheduler is not worth spending time on any more since it's going to be removed soon.
Well, depends. Are there erlang packages that require the UP scheduler?
From your commit log, it looks like the SMP scheduler can cope with non-SMP stuff as well, so there is no risk of breakage.
Thus, I'm fine with not considering a UP option.
Quoted 8 lines
Quoted 3 lines
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.
I'm fine either way. I'm stuck in the thinking that this change isn't identical to the previous behavior, so I'm not sure how to explain it in the commit message. If someone indulges me with text, I'll gladly send a v3 or feel free to merge one of my other versions.
What about:
erlang: remove non-SMP build option
[your commit log]
We do not need to add a legacy entry, because the new behaviour is the same as with the option previously set (i.e. SMP enabled).
Regards,
Yann E. MORIN.
Quoted 27 lines
Frank
Quoted 25 lines
Sorry if I was not explicit enough about this...
Regards,
Yann E. MORIN.Quoted 11 lines
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. |'------------------------------^-------^------------------^--------------------'
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH v2 1/1 erlang: remove non-SMP build option
Yann,
Quoted 63 lines · Yann E. MORIN
Frank, All,
On 2017-12-20 08:52 -0500, Frank Hunleth spake thusly:
Quoted 52 lines · Yann E. MORIN
Quoted 44 lines
On 2017-12-20 11:26 +0100, Thomas Petazzoni spake thusly:
Quoted 29 lines · Frank Hunleth
Quoted 28 lines
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 <[email protected]>---
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(-)Config.in.legacy +0
-0@@ -153,6 +153,16 @@ config BR2_PACKAGE_GNUPG2_GPGV2 The gpgv2 executable is now named gpgv. The config option has been renamed accordingly.Quoted 13 lines
Config.in.legacy config BR2_PACKAGE_GNUPG2_GPGV2 · line 164
Quoted 9 lines
Config.in.legacy +9
-0+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.
Quoted 6 lines
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.
Quoted 5 lines
That's not true. Before if you enabled the option, you'd get the uniprocessor scheduler. With the change, you get the SMP scheduler.
In the .mk file, if you were to enable
BR2_PACKAGE_ERLANG_SMP, that would pass "--disable-smp-support" to the configure script.That's wrong, because the code was:
Quoted 7 lines
ifeq ($(BR2_PACKAGE_ERLANG_SMP),) ERLANG_CONF_OPTS += --disable-smp-support endifIf
BR2_PACKAGE_ERLANG_SMPwas set, it would not fulfill the condition, and we would *not* pass --disable-smp-support. But if it was unset, then the condition would be true, and we'd pass --disable-smp-support.
Ahh, thanks! I think that I've been out of working with Makefiles for too long since now that you point it out, this is completely obvious. Thanks for bearing with me.
Quoted 13 lines
Now, with your change, we will no longer pass --disable-smp-support, ever, so this is back to option enabled.
(note that we can't account for the case where the option was disabled; that's a limitation, but we don't really care).
Quoted 7 lines
That
forces the uniprocessor scheduler. With this patch, you only can get the SMP scheduler. I'm not sure how many people would do this, but operationally, you'd see a process called "beam.smp" running on your system now. The uniprocessor scheduler made a process called "beam". That seems like a different result to me?
Quoted 8 lines
Quoted 6 lines
Looking over the Erlang release notes, the situation may even be worse now since they've added a --enable-plain-scheduler option to build the uniprocessor scheduler, so the current option
BR2_PACKAGE_ERLANG_SMPoption may not even work. I don't know, but the uniprocessor scheduler is not worth spending time on any more since it's going to be removed soon.Well, depends. Are there erlang packages that require the UP scheduler?
Not that I'm aware of. We've been using the SMP scheduler for at least a year across all platforms on the Nerves project and I haven't received a report of anyone having an issue with it. On the other hand, the library that wraps sqlite doesn't work with the UP scheduler and people used to run into that frequently.
Quoted 16 lines
From your commit log, it looks like the SMP scheduler can cope with non-SMP stuff as well, so there is no risk of breakage.
Thus, I'm fine with not considering a UP option.
Quoted 8 lines
Quoted 3 lines
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.
I'm fine either way. I'm stuck in the thinking that this change isn't identical to the previous behavior, so I'm not sure how to explain it in the commit message. If someone indulges me with text, I'll gladly send a v3 or feel free to merge one of my other versions.
What about:
Quoted 8 lines
erlang: remove non-SMP build option
[your commit log]
We do not need to add a legacy entry, because the new behaviour is the same as with the option previously set (i.e. SMP enabled).
Signed-off-by You.
Thank you! Patch coming!
Frank