* [Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL
2014-02-13 13:22 [Buildroot] [PATCH 0/6] Add toolchain knob for NPTL Thomas Petazzoni
@ 2014-02-13 13:22 ` Thomas Petazzoni
2014-02-17 7:11 ` Arnout Vandecappelle
2014-02-17 22:08 ` Arnout Vandecappelle
2014-02-13 13:22 ` [Buildroot] [PATCH 2/6] docs/manual: indicate how to handle BR2_TOOLCHAIN_HAS_THREADS_NPTL Thomas Petazzoni
` (5 subsequent siblings)
6 siblings, 2 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2014-02-13 13:22 UTC (permalink / raw)
To: buildroot
As our architecture support expands to a number of architectures that
do not implement NPTL threading, and the number of packages that
depend on NPTL specific features, it has become necessary to be able
to know whether the toolchain has NPTL support or not.
This commit adds a new BR2_TOOLCHAIN_HAS_THREADS_NPTL hidden Config.in
option that allows packages to know whether NPTL is available or not.
This hidden option is:
* Automatically enabled when glibc/eglibc or musl toolchains are
used, either internal or external.
* Automatically enabled when an internal uClibc toolchain with NPTL
support is configured. It is left disabled otherwise for internal
uClibc toolchains.
* Configured according to a visible Config.in option for custom
external uClibc toolchains.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/uclibc/Config.in | 1 +
toolchain/Config.in | 2 ++
toolchain/helpers.mk | 1 +
toolchain/toolchain-common.in | 3 +++
toolchain/toolchain-external/Config.in | 11 +++++++++++
5 files changed, 18 insertions(+)
diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in
index f5543cc..0ee4125 100644
--- a/package/uclibc/Config.in
+++ b/package/uclibc/Config.in
@@ -124,6 +124,7 @@ choice
config BR2_PTHREADS_NATIVE
bool "Native POSIX Threading (NPTL)"
select BR2_TOOLCHAIN_HAS_THREADS
+ select BR2_TOOLCHAIN_HAS_THREADS_NPTL
depends on !BR2_arc
depends on !BR2_avr32
depends on !BR2_bfin
diff --git a/toolchain/Config.in b/toolchain/Config.in
index bbfd367..44f3ac6 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -9,6 +9,7 @@ config BR2_TOOLCHAIN_USES_GLIBC
select BR2_ENABLE_LOCALE
select BR2_TOOLCHAIN_HAS_THREADS
select BR2_TOOLCHAIN_HAS_THREADS_DEBUG
+ select BR2_TOOLCHAIN_HAS_THREADS_NPTL
select BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS
select BR2_TOOLCHAIN_HAS_SSP
@@ -23,6 +24,7 @@ config BR2_TOOLCHAIN_USES_MUSL
select BR2_ENABLE_LOCALE
select BR2_TOOLCHAIN_HAS_THREADS
select BR2_TOOLCHAIN_HAS_THREADS_DEBUG
+ select BR2_TOOLCHAIN_HAS_THREADS_NPTL
choice
prompt "Toolchain type"
diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk
index faa9d90..892ab4b 100644
--- a/toolchain/helpers.mk
+++ b/toolchain/helpers.mk
@@ -268,6 +268,7 @@ check_uclibc = \
$(call check_uclibc_feature,__UCLIBC_HAS_WCHAR__,BR2_USE_WCHAR,$${UCLIBC_CONFIG_FILE},Wide char support) ;\
$(call check_uclibc_feature,__UCLIBC_HAS_THREADS__,BR2_TOOLCHAIN_HAS_THREADS,$${UCLIBC_CONFIG_FILE},Thread support) ;\
$(call check_uclibc_feature,__PTHREADS_DEBUG_SUPPORT__,BR2_TOOLCHAIN_HAS_THREADS_DEBUG,$${UCLIBC_CONFIG_FILE},Thread debugging support) ;\
+ $(call check_uclibc_feature,__UCLIBC_HAS_THREADS_NATIVE__,BR2_TOOLCHAIN_HAS_THREADS_NPTL,$${UCLIBC_CONFIG_FILE},NPTL thread support) ;\
$(call check_uclibc_feature,__UCLIBC_HAS_SSP__,BR2_TOOLCHAIN_HAS_SSP,$${UCLIBC_CONFIG_FILE},Stack Smashing Protection support)
#
diff --git a/toolchain/toolchain-common.in b/toolchain/toolchain-common.in
index 8435a65..c4e3890 100644
--- a/toolchain/toolchain-common.in
+++ b/toolchain/toolchain-common.in
@@ -29,6 +29,9 @@ config BR2_TOOLCHAIN_HAS_THREADS
config BR2_TOOLCHAIN_HAS_THREADS_DEBUG
bool
+config BR2_TOOLCHAIN_HAS_THREADS_NPTL
+ bool
+
config BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS
bool
diff --git a/toolchain/toolchain-external/Config.in b/toolchain/toolchain-external/Config.in
index f02f89b..c87f195 100644
--- a/toolchain/toolchain-external/Config.in
+++ b/toolchain/toolchain-external/Config.in
@@ -1006,6 +1006,17 @@ config BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG
debugging support. If you don't know, leave the default
value, Buildroot will tell you if it's correct or not.
+config BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_NPTL
+ bool "Toolchain has NPTL threads support?"
+ depends on BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS
+ select BR2_TOOLCHAIN_HAS_THREADS_NPTL
+ default y
+ help
+ Select this option if your external toolchain uses the NPTL
+ (Native Posix Thread Library) implementation of Posix
+ threads. If you don't know, leave the default value,
+ Buildroot will tell you if it's correct or not.
+
config BR2_TOOLCHAIN_EXTERNAL_HAS_SSP
bool "Toolchain has SSP support?"
select BR2_TOOLCHAIN_HAS_SSP
--
1.8.3.2
^ permalink raw reply related [flat|nested] 18+ messages in thread* [Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL
2014-02-13 13:22 ` [Buildroot] [PATCH 1/6] toolchain: introduce a " Thomas Petazzoni
@ 2014-02-17 7:11 ` Arnout Vandecappelle
2014-02-17 8:03 ` Thomas Petazzoni
2014-02-17 22:08 ` Arnout Vandecappelle
1 sibling, 1 reply; 18+ messages in thread
From: Arnout Vandecappelle @ 2014-02-17 7:11 UTC (permalink / raw)
To: buildroot
On 13/02/14 14:22, Thomas Petazzoni wrote:
> As our architecture support expands to a number of architectures that
> do not implement NPTL threading, and the number of packages that
> depend on NPTL specific features, it has become necessary to be able
> to know whether the toolchain has NPTL support or not.
>
> This commit adds a new BR2_TOOLCHAIN_HAS_THREADS_NPTL hidden Config.in
> option that allows packages to know whether NPTL is available or not.
>
> This hidden option is:
>
> * Automatically enabled when glibc/eglibc or musl toolchains are
> used, either internal or external.
>
> * Automatically enabled when an internal uClibc toolchain with NPTL
> support is configured. It is left disabled otherwise for internal
> uClibc toolchains.
>
> * Configured according to a visible Config.in option for custom
> external uClibc toolchains.
I think there is very little reason left to use NPTL on archs that
support it, isn't there? So I would first remove the option completely
for these architectures. That would also make adding a comment
unnecessary (since it becomes an architecture feature rather than a
toolchain option).
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL
2014-02-17 7:11 ` Arnout Vandecappelle
@ 2014-02-17 8:03 ` Thomas Petazzoni
2014-02-17 16:59 ` Arnout Vandecappelle
0 siblings, 1 reply; 18+ messages in thread
From: Thomas Petazzoni @ 2014-02-17 8:03 UTC (permalink / raw)
To: buildroot
Dear Arnout Vandecappelle,
On Mon, 17 Feb 2014 08:11:54 +0100, Arnout Vandecappelle wrote:
> I think there is very little reason left to use NPTL on archs that
I guess you wanted to say "to *NOT* use NPTL".
> support it, isn't there? So I would first remove the option completely
> for these architectures. That would also make adding a comment
> unnecessary (since it becomes an architecture feature rather than a
> toolchain option).
While I definitely agree for the internal toolchain backend, I don't
think this applies nicely with the external toolchain backend. We do
not control how the external toolchains are built, and it is perfectly
possible to build a non-NPTL toolchain on a NPTL-supported architecture
with Crosstool-NG for example.
That being said, our choice could simply be to not support these cases
at all, and check in the external toolchain backend that the toolchain
has NPTL support if the architecture is supposed to support it.
However, this kind of strategy might fail quite quickly for "growing"
architectures. For example, ARC currently does not have NPTL support,
but since they appear to be quite active, maybe they will implement
NPTL support at some point. And at this moment we will have a range of
stable, well-tested toolchains that are non-NPTL, and the possibility
of building NPTL-capable, but not fully tested toolchains.
Thoughts?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL
2014-02-17 8:03 ` Thomas Petazzoni
@ 2014-02-17 16:59 ` Arnout Vandecappelle
2014-02-17 22:51 ` Thomas Petazzoni
0 siblings, 1 reply; 18+ messages in thread
From: Arnout Vandecappelle @ 2014-02-17 16:59 UTC (permalink / raw)
To: buildroot
On 17/02/14 09:03, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Mon, 17 Feb 2014 08:11:54 +0100, Arnout Vandecappelle wrote:
>
>> I think there is very little reason left to use NPTL on archs that
>
> I guess you wanted to say "to *NOT* use NPTL".
Good guess :-)
>
>> support it, isn't there? So I would first remove the option completely
>> for these architectures. That would also make adding a comment
>> unnecessary (since it becomes an architecture feature rather than a
>> toolchain option).
>
> While I definitely agree for the internal toolchain backend, I don't
> think this applies nicely with the external toolchain backend. We do
> not control how the external toolchains are built, and it is perfectly
> possible to build a non-NPTL toolchain on a NPTL-supported architecture
> with Crosstool-NG for example.
Yes, but we certainly don't support all of the possible toolchains that
can be spat out by Crosstool-NG. At least, I don't think so...
> That being said, our choice could simply be to not support these cases
> at all, and check in the external toolchain backend that the toolchain
> has NPTL support if the architecture is supposed to support it.
... therefore I'd be in favour of this approach.
>
> However, this kind of strategy might fail quite quickly for "growing"
> architectures. For example, ARC currently does not have NPTL support,
> but since they appear to be quite active, maybe they will implement
> NPTL support at some point. And at this moment we will have a range of
> stable, well-tested toolchains that are non-NPTL, and the possibility
> of building NPTL-capable, but not fully tested toolchains.
But that's indeed a very good point that I didn't think of. Indeed, for
these we'll want to support both NPTL and LinuxThreads, therefore we
still need the comments.
Taking that aspect into consideration, removing the LinuxThreads options
is not bringing any real advantage. So forget I ever mentioned it :-)
Regards,
Arnout
>
> Thoughts?
>
> Best regards,
>
> Thomas
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL
2014-02-17 16:59 ` Arnout Vandecappelle
@ 2014-02-17 22:51 ` Thomas Petazzoni
0 siblings, 0 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2014-02-17 22:51 UTC (permalink / raw)
To: buildroot
Dear Arnout Vandecappelle,
On Mon, 17 Feb 2014 17:59:33 +0100, Arnout Vandecappelle wrote:
> >> support it, isn't there? So I would first remove the option completely
> >> for these architectures. That would also make adding a comment
> >> unnecessary (since it becomes an architecture feature rather than a
> >> toolchain option).
> >
> > While I definitely agree for the internal toolchain backend, I don't
> > think this applies nicely with the external toolchain backend. We do
> > not control how the external toolchains are built, and it is perfectly
> > possible to build a non-NPTL toolchain on a NPTL-supported architecture
> > with Crosstool-NG for example.
>
> Yes, but we certainly don't support all of the possible toolchains that
> can be spat out by Crosstool-NG. At least, I don't think so...
We are supposed to support a good number of possible toolchains that
Crosstool-NG generates, even though it's true that we do not support
all the possible funky uClibc configurations that one could create with
Crosstool-NG. We also don't support these in Buildroot, while we do
ensure that the uClibc configuration matches the threading model
selected in the Buildroot configuration.
> > However, this kind of strategy might fail quite quickly for "growing"
> > architectures. For example, ARC currently does not have NPTL support,
> > but since they appear to be quite active, maybe they will implement
> > NPTL support at some point. And at this moment we will have a range of
> > stable, well-tested toolchains that are non-NPTL, and the possibility
> > of building NPTL-capable, but not fully tested toolchains.
>
> But that's indeed a very good point that I didn't think of. Indeed, for
> these we'll want to support both NPTL and LinuxThreads, therefore we
> still need the comments.
>
> Taking that aspect into consideration, removing the LinuxThreads options
> is not bringing any real advantage. So forget I ever mentioned it :-)
Ok, thanks for your feedback!
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL
2014-02-13 13:22 ` [Buildroot] [PATCH 1/6] toolchain: introduce a " Thomas Petazzoni
2014-02-17 7:11 ` Arnout Vandecappelle
@ 2014-02-17 22:08 ` Arnout Vandecappelle
2014-02-17 22:57 ` Thomas Petazzoni
1 sibling, 1 reply; 18+ messages in thread
From: Arnout Vandecappelle @ 2014-02-17 22:08 UTC (permalink / raw)
To: buildroot
On 13/02/14 14:22, Thomas Petazzoni wrote:
> +config BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_NPTL
> + bool "Toolchain has NPTL threads support?"
> + depends on BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS
> + select BR2_TOOLCHAIN_HAS_THREADS_NPTL
> + default y
> + help
> + Select this option if your external toolchain uses the NPTL
> + (Native Posix Thread Library) implementation of Posix
> + threads. If you don't know, leave the default value,
> + Buildroot will tell you if it's correct or not.
Where exactly does buildroot check if the external toolchain has NPTL?
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL
2014-02-17 22:08 ` Arnout Vandecappelle
@ 2014-02-17 22:57 ` Thomas Petazzoni
2014-02-17 23:09 ` Arnout Vandecappelle
0 siblings, 1 reply; 18+ messages in thread
From: Thomas Petazzoni @ 2014-02-17 22:57 UTC (permalink / raw)
To: buildroot
Dear Arnout Vandecappelle,
On Mon, 17 Feb 2014 23:08:15 +0100, Arnout Vandecappelle wrote:
> On 13/02/14 14:22, Thomas Petazzoni wrote:
> > +config BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_NPTL
> > + bool "Toolchain has NPTL threads support?"
> > + depends on BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS
> > + select BR2_TOOLCHAIN_HAS_THREADS_NPTL
> > + default y
> > + help
> > + Select this option if your external toolchain uses the NPTL
> > + (Native Posix Thread Library) implementation of Posix
> > + threads. If you don't know, leave the default value,
> > + Buildroot will tell you if it's correct or not.
>
> Where exactly does buildroot check if the external toolchain has NPTL?
In the patch you're replying to, look at the chunk that modifies
toolchain/helpers.mk:
+ $(call check_uclibc_feature,__UCLIBC_HAS_THREADS_NATIVE__,BR2_TOOLCHAIN_HAS_THREADS_NPTL,$${UCLIBC_CONFIG_FILE},NPTL thread support) ;\
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 18+ messages in thread* [Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL
2014-02-17 22:57 ` Thomas Petazzoni
@ 2014-02-17 23:09 ` Arnout Vandecappelle
0 siblings, 0 replies; 18+ messages in thread
From: Arnout Vandecappelle @ 2014-02-17 23:09 UTC (permalink / raw)
To: buildroot
On 17/02/14 23:57, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Mon, 17 Feb 2014 23:08:15 +0100, Arnout Vandecappelle wrote:
>> On 13/02/14 14:22, Thomas Petazzoni wrote:
>>> +config BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_NPTL
>>> + bool "Toolchain has NPTL threads support?"
>>> + depends on BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS
>>> + select BR2_TOOLCHAIN_HAS_THREADS_NPTL
>>> + default y
>>> + help
>>> + Select this option if your external toolchain uses the NPTL
>>> + (Native Posix Thread Library) implementation of Posix
>>> + threads. If you don't know, leave the default value,
>>> + Buildroot will tell you if it's correct or not.
>>
>> Where exactly does buildroot check if the external toolchain has NPTL?
>
> In the patch you're replying to, look at the chunk that modifies
> toolchain/helpers.mk:
>
> + $(call check_uclibc_feature,__UCLIBC_HAS_THREADS_NATIVE__,BR2_TOOLCHAIN_HAS_THREADS_NPTL,$${UCLIBC_CONFIG_FILE},NPTL thread support) ;\
Damn, I looked for it three times and couldn't find it... Better get my
eyes checked!
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 2/6] docs/manual: indicate how to handle BR2_TOOLCHAIN_HAS_THREADS_NPTL
2014-02-13 13:22 [Buildroot] [PATCH 0/6] Add toolchain knob for NPTL Thomas Petazzoni
2014-02-13 13:22 ` [Buildroot] [PATCH 1/6] toolchain: introduce a " Thomas Petazzoni
@ 2014-02-13 13:22 ` Thomas Petazzoni
2014-02-13 13:46 ` Thomas De Schampheleire
2014-02-13 13:22 ` [Buildroot] [PATCH 3/6] rt-tests: use BR2_TOOLCHAIN_HAS_THREADS_NPTL Thomas Petazzoni
` (4 subsequent siblings)
6 siblings, 1 reply; 18+ messages in thread
From: Thomas Petazzoni @ 2014-02-13 13:22 UTC (permalink / raw)
To: buildroot
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
docs/manual/adding-packages-directory.txt | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/docs/manual/adding-packages-directory.txt b/docs/manual/adding-packages-directory.txt
index 754a145..e1299c3 100644
--- a/docs/manual/adding-packages-directory.txt
+++ b/docs/manual/adding-packages-directory.txt
@@ -235,7 +235,13 @@ use in the comment.
* thread support
** Dependency symbol: +BR2_TOOLCHAIN_HAS_THREADS+
-** Comment string: +threads+
+** Comment string: +threads+ (unless +BR2_TOOLCHAIN_HAS_THREADS_NPTL+
+ is also needed, in which case, specifying only +NPTL threads+ is
+ sufficient)
+
+* NPTL thread support
+** Dependency symbol: +BR2_TOOLCHAIN_HAS_THREADS_NPTL+
+** Comment string: +NPTL threads+
* RPC support
** Dependency symbol: +BR2_TOOLCHAIN_HAS_NATIVE_RPC+
--
1.8.3.2
^ permalink raw reply related [flat|nested] 18+ messages in thread* [Buildroot] [PATCH 2/6] docs/manual: indicate how to handle BR2_TOOLCHAIN_HAS_THREADS_NPTL
2014-02-13 13:22 ` [Buildroot] [PATCH 2/6] docs/manual: indicate how to handle BR2_TOOLCHAIN_HAS_THREADS_NPTL Thomas Petazzoni
@ 2014-02-13 13:46 ` Thomas De Schampheleire
2014-02-13 13:55 ` Thomas Petazzoni
0 siblings, 1 reply; 18+ messages in thread
From: Thomas De Schampheleire @ 2014-02-13 13:46 UTC (permalink / raw)
To: buildroot
On Thu, Feb 13, 2014 at 2:22 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> docs/manual/adding-packages-directory.txt | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/docs/manual/adding-packages-directory.txt b/docs/manual/adding-packages-directory.txt
> index 754a145..e1299c3 100644
> --- a/docs/manual/adding-packages-directory.txt
> +++ b/docs/manual/adding-packages-directory.txt
> @@ -235,7 +235,13 @@ use in the comment.
>
> * thread support
> ** Dependency symbol: +BR2_TOOLCHAIN_HAS_THREADS+
> -** Comment string: +threads+
> +** Comment string: +threads+ (unless +BR2_TOOLCHAIN_HAS_THREADS_NPTL+
> + is also needed, in which case, specifying only +NPTL threads+ is
> + sufficient)
> +
> +* NPTL thread support
> +** Dependency symbol: +BR2_TOOLCHAIN_HAS_THREADS_NPTL+
> +** Comment string: +NPTL threads+
>
> * RPC support
> ** Dependency symbol: +BR2_TOOLCHAIN_HAS_NATIVE_RPC+
Should we maybe use 'NPTL' rather than 'NPTL threads' to make the
string shorter? (we want to fit in 80chars).
It's true that it's a bit more cryptic, but so is RPC, wchar, etc.
The biggest point is that a user can go to the Toolchain menu and
recognize a string that matches, in this case the keyword NPTL.
Best regards,
Thomas
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 2/6] docs/manual: indicate how to handle BR2_TOOLCHAIN_HAS_THREADS_NPTL
2014-02-13 13:46 ` Thomas De Schampheleire
@ 2014-02-13 13:55 ` Thomas Petazzoni
0 siblings, 0 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2014-02-13 13:55 UTC (permalink / raw)
To: buildroot
Dear Thomas De Schampheleire,
On Thu, 13 Feb 2014 14:46:00 +0100, Thomas De Schampheleire wrote:
> > * thread support
> > ** Dependency symbol: +BR2_TOOLCHAIN_HAS_THREADS+
> > -** Comment string: +threads+
> > +** Comment string: +threads+ (unless +BR2_TOOLCHAIN_HAS_THREADS_NPTL+
> > + is also needed, in which case, specifying only +NPTL threads+ is
> > + sufficient)
> > +
> > +* NPTL thread support
> > +** Dependency symbol: +BR2_TOOLCHAIN_HAS_THREADS_NPTL+
> > +** Comment string: +NPTL threads+
> >
> > * RPC support
> > ** Dependency symbol: +BR2_TOOLCHAIN_HAS_NATIVE_RPC+
>
> Should we maybe use 'NPTL' rather than 'NPTL threads' to make the
> string shorter? (we want to fit in 80chars).
> It's true that it's a bit more cryptic, but so is RPC, wchar, etc.
> The biggest point is that a user can go to the Toolchain menu and
> recognize a string that matches, in this case the keyword NPTL.
Fine with me. I'll adjust that in the v2, but I'll wait a little bit
more for other comments, if any :)
Thanks for the review!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Buildroot] [PATCH 3/6] rt-tests: use BR2_TOOLCHAIN_HAS_THREADS_NPTL
2014-02-13 13:22 [Buildroot] [PATCH 0/6] Add toolchain knob for NPTL Thomas Petazzoni
2014-02-13 13:22 ` [Buildroot] [PATCH 1/6] toolchain: introduce a " Thomas Petazzoni
2014-02-13 13:22 ` [Buildroot] [PATCH 2/6] docs/manual: indicate how to handle BR2_TOOLCHAIN_HAS_THREADS_NPTL Thomas Petazzoni
@ 2014-02-13 13:22 ` Thomas Petazzoni
2014-02-13 13:22 ` [Buildroot] [PATCH 4/6] sconeserver: " Thomas Petazzoni
` (3 subsequent siblings)
6 siblings, 0 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2014-02-13 13:22 UTC (permalink / raw)
To: buildroot
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/rt-tests/Config.in | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/package/rt-tests/Config.in b/package/rt-tests/Config.in
index 58a88a8..55e4f55 100644
--- a/package/rt-tests/Config.in
+++ b/package/rt-tests/Config.in
@@ -1,10 +1,6 @@
config BR2_PACKAGE_RT_TESTS
bool "rt-tests"
- depends on BR2_TOOLCHAIN_HAS_THREADS
- # priority-inheritance mutex needs NPTL
- depends on !BR2_PTHREADS && !BR2_PTHREADS_OLD
- # no NPTL for these archs
- depends on !BR2_avr32 && !BR2_xtensa && !BR2_arc
+ depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL
help
Set of utilities for testing the real-time behaviour of a
Linux system.
@@ -23,7 +19,5 @@ config BR2_PACKAGE_RT_TESTS
http://rt.wiki.kernel.org
-comment "rt-tests needs a toolchain w/ threads"
- depends on !BR2_PTHREADS && !BR2_PTHREADS_OLD
- depends on !BR2_avr32 && !BR2_xtensa && !BR2_arc
- depends on !BR2_TOOLCHAIN_HAS_THREADS
+comment "rt-tests needs a toolchain w/ NPTL threads"
+ depends on !BR2_TOOLCHAIN_HAS_THREADS_NPTL
--
1.8.3.2
^ permalink raw reply related [flat|nested] 18+ messages in thread* [Buildroot] [PATCH 4/6] sconeserver: use BR2_TOOLCHAIN_HAS_THREADS_NPTL
2014-02-13 13:22 [Buildroot] [PATCH 0/6] Add toolchain knob for NPTL Thomas Petazzoni
` (2 preceding siblings ...)
2014-02-13 13:22 ` [Buildroot] [PATCH 3/6] rt-tests: use BR2_TOOLCHAIN_HAS_THREADS_NPTL Thomas Petazzoni
@ 2014-02-13 13:22 ` Thomas Petazzoni
2014-02-13 13:22 ` [Buildroot] [PATCH 5/6] tvheadend: " Thomas Petazzoni
` (2 subsequent siblings)
6 siblings, 0 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2014-02-13 13:22 UTC (permalink / raw)
To: buildroot
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/sconeserver/Config.in | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/package/sconeserver/Config.in b/package/sconeserver/Config.in
index ccb9c00..ac7a2b9 100644
--- a/package/sconeserver/Config.in
+++ b/package/sconeserver/Config.in
@@ -1,11 +1,7 @@
menuconfig BR2_PACKAGE_SCONESERVER
bool "sconeserver"
depends on BR2_INSTALL_LIBSTDCPP
- depends on BR2_TOOLCHAIN_HAS_THREADS
- # pthread_setschedprio needs NPTL
- depends on !BR2_PTHREADS && !BR2_PTHREADS_OLD
- # no NPTL for these archs
- depends on !BR2_avr32 && !BR2_xtensa && !BR2_arc
+ depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL
select BR2_PACKAGE_PCRE
help
Sconeserver is a modular, object-orientated and extremely versatile
@@ -102,7 +98,5 @@ comment "ui module requires X.org"
endif # BR2_PACKAGE_SCONESERVER
-comment "sconeserver needs a toolchain w/ C++, threads"
- depends on !(BR2_INSTALL_LIBSTDCPP && BR2_TOOLCHAIN_HAS_THREADS)
- depends on !BR2_PTHREADS && !BR2_PTHREADS_OLD
- depends on !BR2_avr32 && !BR2_xtensa && !BR2_arc
+comment "sconeserver needs a toolchain w/ C++, NPTL threads"
+ depends on !(BR2_INSTALL_LIBSTDCPP && BR2_TOOLCHAIN_HAS_THREADS_NPTL)
--
1.8.3.2
^ permalink raw reply related [flat|nested] 18+ messages in thread* [Buildroot] [PATCH 5/6] tvheadend: use BR2_TOOLCHAIN_HAS_THREADS_NPTL
2014-02-13 13:22 [Buildroot] [PATCH 0/6] Add toolchain knob for NPTL Thomas Petazzoni
` (3 preceding siblings ...)
2014-02-13 13:22 ` [Buildroot] [PATCH 4/6] sconeserver: " Thomas Petazzoni
@ 2014-02-13 13:22 ` Thomas Petazzoni
2014-02-13 13:22 ` [Buildroot] [PATCH 6/6] qt5: needs NPTL threads Thomas Petazzoni
2014-02-13 13:46 ` [Buildroot] [PATCH 0/6] Add toolchain knob for NPTL Mike Zick
6 siblings, 0 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2014-02-13 13:22 UTC (permalink / raw)
To: buildroot
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/tvheadend/Config.in | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/package/tvheadend/Config.in b/package/tvheadend/Config.in
index da60f83..ac4a192 100644
--- a/package/tvheadend/Config.in
+++ b/package/tvheadend/Config.in
@@ -1,22 +1,16 @@
-comment "tvheadend needs a toolchain w/ largefile, IPv6, threads"
- depends on !BR2_avr32 && !BR2_xtensa && !BR2_arc
- depends on !BR2_PTHREADS && !BR2_PTHREADS_OLD
- depends on !BR2_LARGEFILE || !BR2_INET_IPV6 || !BR2_TOOLCHAIN_HAS_THREADS
+comment "tvheadend needs a toolchain w/ largefile, IPv6, NPTL threads"
+ depends on !BR2_LARGEFILE || !BR2_INET_IPV6 || !BR2_TOOLCHAIN_HAS_THREADS_NPTL
config BR2_PACKAGE_TVHEADEND
bool "tvheadend"
depends on BR2_LARGEFILE && BR2_INET_IPV6
- depends on BR2_TOOLCHAIN_HAS_THREADS
+ depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL
# tvheadend requires an atomic_add operation. Either you have
# a gcc >= 4.3 toolchain and it uses the gcc intrinsics, or it
# has special code for x86, x86-64, PPC and ARM. So in the
# context of Buildroot, the only really problematic
# architecture is avr32, which uses gcc 4.2.
depends on !BR2_avr32
- # clock_nanosleep needs NPTL
- depends on !BR2_PTHREADS && !BR2_PTHREADS_OLD
- # no NPTL for these archs
- depends on !BR2_xtensa && !BR2_arc
select BR2_PACKAGE_DVB_APPS
select BR2_PACKAGE_OPENSSL
help
--
1.8.3.2
^ permalink raw reply related [flat|nested] 18+ messages in thread* [Buildroot] [PATCH 6/6] qt5: needs NPTL threads
2014-02-13 13:22 [Buildroot] [PATCH 0/6] Add toolchain knob for NPTL Thomas Petazzoni
` (4 preceding siblings ...)
2014-02-13 13:22 ` [Buildroot] [PATCH 5/6] tvheadend: " Thomas Petazzoni
@ 2014-02-13 13:22 ` Thomas Petazzoni
2014-02-13 13:46 ` [Buildroot] [PATCH 0/6] Add toolchain knob for NPTL Mike Zick
6 siblings, 0 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2014-02-13 13:22 UTC (permalink / raw)
To: buildroot
Fixes:
http://autobuild.buildroot.org/results/70b/70b77e7a5b292e3fcbcf8cab4651c48220f2bd17/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/qt5/Config.in | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/package/qt5/Config.in b/package/qt5/Config.in
index b62a810..597dbd1 100644
--- a/package/qt5/Config.in
+++ b/package/qt5/Config.in
@@ -6,10 +6,10 @@ config BR2_PACKAGE_QT5_JSCORE_AVAILABLE
depends on !(BR2_arm7tdmi || BR2_arm720t || BR2_arm920t || BR2_arm922t || BR2_fa526)
default y
-comment "Qt5 needs a toolchain w/ wchar, IPv6, threads, C++"
+comment "Qt5 needs a toolchain w/ wchar, IPv6, NPTL threads, C++"
depends on !BR2_PACKAGE_QT
depends on !BR2_avr32
- depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR || !BR2_INET_IPV6 || !BR2_TOOLCHAIN_HAS_THREADS
+ depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR || !BR2_INET_IPV6 || !BR2_TOOLCHAIN_HAS_THREADS_NPTL
menuconfig BR2_PACKAGE_QT5
bool "Qt5"
@@ -17,7 +17,7 @@ menuconfig BR2_PACKAGE_QT5
depends on BR2_INSTALL_LIBSTDCPP
depends on BR2_USE_WCHAR
depends on BR2_INET_IPV6
- depends on BR2_TOOLCHAIN_HAS_THREADS
+ depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL
depends on !BR2_PACKAGE_QT
help
This option enables the Qt5 framework. Sub-options allow to
--
1.8.3.2
^ permalink raw reply related [flat|nested] 18+ messages in thread* [Buildroot] [PATCH 0/6] Add toolchain knob for NPTL
2014-02-13 13:22 [Buildroot] [PATCH 0/6] Add toolchain knob for NPTL Thomas Petazzoni
` (5 preceding siblings ...)
2014-02-13 13:22 ` [Buildroot] [PATCH 6/6] qt5: needs NPTL threads Thomas Petazzoni
@ 2014-02-13 13:46 ` Mike Zick
2014-02-18 21:06 ` Thomas Petazzoni
6 siblings, 1 reply; 18+ messages in thread
From: Mike Zick @ 2014-02-13 13:46 UTC (permalink / raw)
To: buildroot
On Thu, 13 Feb 2014 14:22:01 +0100
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> We have a growing number of packages that need pthread functions only
> available when the NPTL implementation is used. But at the same time,
> we have several architectures (AVR32, ARC, Blackfin and Xtensa) that
> don't support NPTL.
>
> This set of commits adds a new hidden toolchain config knob named
> BR2_TOOLCHAIN_HAS_THREADS_NPTL, and uses it in four packages: three
> were already having special conditions to more-or-less detect the
> availability of NPTL, and one package (qt5) which fixes an autobuilder
> failure.
*NIT* :
With the line length limitations, shouldn't variable names be kept to
less than 1/2 the line length limits? ;)
Rhetorical:
Can a toolchain **without threads** support NPTL ?
With the above considerations, perhaps the knob could be:
BR2_TOOLCHAIN_NPTL
- - - -
Sorry for the noise, mind is not fully in-gear this morning.
Mike
^ permalink raw reply [flat|nested] 18+ messages in thread* [Buildroot] [PATCH 0/6] Add toolchain knob for NPTL
2014-02-13 13:46 ` [Buildroot] [PATCH 0/6] Add toolchain knob for NPTL Mike Zick
@ 2014-02-18 21:06 ` Thomas Petazzoni
0 siblings, 0 replies; 18+ messages in thread
From: Thomas Petazzoni @ 2014-02-18 21:06 UTC (permalink / raw)
To: buildroot
Dear Mike Zick,
On Thu, 13 Feb 2014 07:46:17 -0600, Mike Zick wrote:
> With the line length limitations, shouldn't variable names be kept to
> less than 1/2 the line length limits? ;)
BR2_TOOLCHAIN_HAS_THREADS_NPTL is only 30 characters, which is less
than 1/2 the line length limit :)
> Rhetorical:
> Can a toolchain **without threads** support NPTL ?
No, indeed not.
> With the above considerations, perhaps the knob could be:
> BR2_TOOLCHAIN_NPTL
I don't like this, because it's not very expressive. I could reduce it
to BR2_TOOLCHAIN_HAS_NPTL indeed, but I find
BR2_TOOLCHAIN_HAS_THREADS_NPTL to be more expressive. Do others have
different opinions?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 18+ messages in thread