| Message ID | 1392297727-17627-2-git-send-email-thomas.petazzoni@free-electrons.com |
|---|---|
| State | Superseded |
| Headers | show |
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
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
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 >
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
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
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
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
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
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(+)