[Buildroot] [PATCH 0/6] Add toolchain knob for NPTL

[Buildroot] [PATCH 0/6] Add toolchain knob for NPTL

[Thomas Petazzoni]

Hello,

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.

Thomas

Thomas Petazzoni (6):
  toolchain: introduce a toolchain knob for NPTL
  docs/manual: indicate how to handle BR2_TOOLCHAIN_HAS_THREADS_NPTL
  rt-tests: use BR2_TOOLCHAIN_HAS_THREADS_NPTL
  sconeserver: use BR2_TOOLCHAIN_HAS_THREADS_NPTL
  tvheadend: use BR2_TOOLCHAIN_HAS_THREADS_NPTL
  qt5: needs NPTL threads

 docs/manual/adding-packages-directory.txt |  8 +++++++-
 package/qt5/Config.in                     |  6 +++---
 package/rt-tests/Config.in                | 12 +++---------
 package/sconeserver/Config.in             | 12 +++---------
 package/tvheadend/Config.in               | 12 +++---------
 package/uclibc/Config.in                  |  1 +
 toolchain/Config.in                       |  2 ++
 toolchain/helpers.mk                      |  1 +
 toolchain/toolchain-common.in             |  3 +++
 toolchain/toolchain-external/Config.in    | 11 +++++++++++
 10 files changed, 37 insertions(+), 31 deletions(-)

-- 
1.8.3.2

[Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL

[Thomas Petazzoni]

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

[Buildroot] [PATCH 2/6] docs/manual: indicate how to handle BR2_TOOLCHAIN_HAS_THREADS_NPTL

[Thomas Petazzoni]

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

[Buildroot] [PATCH 3/6] rt-tests: use BR2_TOOLCHAIN_HAS_THREADS_NPTL

[Thomas Petazzoni]

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

[Buildroot] [PATCH 4/6] sconeserver: use BR2_TOOLCHAIN_HAS_THREADS_NPTL

[Thomas Petazzoni]

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

[Buildroot] [PATCH 5/6] tvheadend: use BR2_TOOLCHAIN_HAS_THREADS_NPTL

[Thomas Petazzoni]

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

[Buildroot] [PATCH 6/6] qt5: needs NPTL threads

[Thomas Petazzoni]

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

[Buildroot] [PATCH 2/6] docs/manual: indicate how to handle BR2_TOOLCHAIN_HAS_THREADS_NPTL

[Thomas De Schampheleire]

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

[Buildroot] [PATCH 0/6] Add toolchain knob for NPTL

[Mike Zick]

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

[Buildroot] [PATCH 2/6] docs/manual: indicate how to handle BR2_TOOLCHAIN_HAS_THREADS_NPTL

[Thomas Petazzoni]

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

[Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL

[Arnout Vandecappelle]

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

[Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL

[Thomas Petazzoni]

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

[Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL

[Arnout Vandecappelle]

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

[Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL

[Arnout Vandecappelle]

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

[Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL

[Thomas Petazzoni]

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

[Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL

[Thomas Petazzoni]

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

[Buildroot] [PATCH 1/6] toolchain: introduce a toolchain knob for NPTL

[Arnout Vandecappelle]

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

[Buildroot] [PATCH 0/6] Add toolchain knob for NPTL

[Thomas Petazzoni]

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