Re: [uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hello, On Tue, 28 Feb 2017 22:02:27 +0300, Vlad Zakharov wrote: > This commit enables getpt() support in ARC defconfigs as some packages > need it. E.g. we need this to be able to build xterm package as it uses > getpt(). > > As an example I can refer to buildroot autobuilds where xterm build is > failing when using prebuilt ARC toolchain (which in its turn uses uClibc > without getpt() support): > http://autobuild.buildroot.net/results/28a/28a92049a6ceef005787c5779f77ecf3fe8ad642/build-end.log > > Signed-off-by: Vlad Zakharov > --- > extra/Configs/defconfigs/arc/arcv2_defconfig | 1 + > extra/Configs/defconfigs/arc/defconfig | 1 + > 2 files changed, 2 insertions(+) That's more of a question for Waldemar: does it really makes sense to have defconfigs for each architecture? I mean how do they differ between each other? For example, the ARC arcv2_defconfig and defconfig only differ by the option CONFIG_ARC_CPU_HS, whose only purpose is to pass -mcpu=archs. Shouldn't be the solution used on ARM (removing all options to select the compiler flags, and leave it to the user to pass the appropriate options) be used as well ? So, are they really useful? Shouldn't uclibc-ng instead come with just one or two defconfigs, like a "minimal" one and "full-featured" one? Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs
On 03/01/2017 07:25 AM, Thomas Petazzoni wrote: > Hello, > > On Tue, 28 Feb 2017 22:02:27 +0300, Vlad Zakharov wrote: >> This commit enables getpt() support in ARC defconfigs as some packages >> need it. E.g. we need this to be able to build xterm package as it uses >> getpt(). >> >> As an example I can refer to buildroot autobuilds where xterm build is >> failing when using prebuilt ARC toolchain (which in its turn uses uClibc >> without getpt() support): >> https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_28a_28a92049a6ceef005787c5779f77ecf3fe8ad642_build-2Dend.log&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=ziY-j5w_cIfohygKzr-OKfk6T_9nr9g3b-kimHZMkxg&s=Bi2mbuDCVZlzqIZy-ahLFXcNKXbqMMobAcwsnHR99yA&e= >> >> >> Signed-off-by: Vlad Zakharov >> --- >> extra/Configs/defconfigs/arc/arcv2_defconfig | 1 + >> extra/Configs/defconfigs/arc/defconfig | 1 + >> 2 files changed, 2 insertions(+) > That's more of a question for Waldemar: does it really makes sense to > have defconfigs for each architecture? I mean how do they differ > between each other? > > For example, the ARC arcv2_defconfig and defconfig only differ by the > option CONFIG_ARC_CPU_HS, whose only purpose is to pass -mcpu=archs. > Shouldn't be the solution used on ARM (removing all options to select > the compiler flags, and leave it to the user to pass the appropriate > options) be used as well ? Yeah that would work fine I guess ! > So, are they really useful? Shouldn't uclibc-ng instead come with just > one or two defconfigs, like a "minimal" one and "full-featured" one? totally agree and I've historically been pushing back on patches from Alexey et all where we wanted to enable toggles to get buildroot packages building. That was a fair requirement on their part but it kept bloating uClibc for our typical embedded use. But this idea of minimal vs. full featured is exactly what we need. @Alexey / @vlad can we take this up please ! Thx, -Vineet > > Best regards, > > Thomas ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hi Vineet, On Wed, 2017-03-01 at 10:00 -0800, Vineet Gupta wrote: > On 03/01/2017 07:25 AM, Thomas Petazzoni wrote: > > > > Hello, > > > > On Tue, 28 Feb 2017 22:02:27 +0300, Vlad Zakharov wrote: > > > > > > This commit enables getpt() support in ARC defconfigs as some packages > > > need it. E.g. we need this to be able to build xterm package as it uses > > > getpt(). > > > > > > As an example I can refer to buildroot autobuilds where xterm build is > > > failing when using prebuilt ARC toolchain (which in its turn uses uClibc > > > without getpt() support): > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.buildroot.net_results_28a_28a92049a6ceef005787c5779f77ecf3fe8ad642_build-2Dend.log > > > &d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=ziY-j5w_cIfohygKzr-OKfk6T_9nr9g3b- > > > kimHZMkxg&s=Bi2mbuDCVZlzqIZy-ahLFXcNKXbqMMobAcwsnHR99yA&e= > > > > > > Signed-off-by: Vlad Zakharov > > > --- > > > extra/Configs/defconfigs/arc/arcv2_defconfig | 1 + > > > extra/Configs/defconfigs/arc/defconfig | 1 + > > > 2 files changed, 2 insertions(+) > > That's more of a question for Waldemar: does it really makes sense to > > have defconfigs for each architecture? I mean how do they differ > > between each other? > > > > For example, the ARC arcv2_defconfig and defconfig only differ by the > > option CONFIG_ARC_CPU_HS, whose only purpose is to pass -mcpu=archs. > > Shouldn't be the solution used on ARM (removing all options to select > > the compiler flags, and leave it to the user to pass the appropriate > > options) be used as well ? > > Yeah that would work fine I guess ! That means for building of our toolchain we'll need to have separately stored "defconfigs" in some form. Let's see what Anton says on that :) And regardless of what mr Anton says having off-the-tree defconfigs is not the best idea because with time options will go in and out and occasionally we'll have outdated defconfigs. > > > > So, are they really useful? Shouldn't uclibc-ng instead come with just > > one or two defconfigs, like a "minimal" one and "full-featured" one? > > totally agree and I've historically been pushing back on patches from Alexey > et > all where we wanted to enable toggles to get buildroot packages building. Those changes I made to make sure our prebuilt toolchain is useful for building more packages. I.e. to be in one camp with Mentor's (AKA CodeSourcery) prebuilt tools that are really capable. > That was > a fair requirement on their part but it kept bloating uClibc for our typical > embedded use. But this idea of minimal vs. full featured is exactly what we > need. > @Alexey / @vlad can we take this up please ! Probably Waldemar's opinion might be useful here. @Waldemar are there any plans for busting arch-specific defconfigs in favor to generic defconfigs like those "minimal" and "full" mentioned above? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs
On 03/01/2017 10:25 AM, Alexey Brodkin wrote: >> That was >> a fair requirement on their part but it kept bloating uClibc for our typical >> embedded use. But this idea of minimal vs. full featured is exactly what we >> need. >> @Alexey / @vlad can we take this up please ! > Probably Waldemar's opinion might be useful here. > @Waldemar are there any plans for busting arch-specific defconfigs in favor > to generic defconfigs like those "minimal" and "full" mentioned above? I didn't read Thomas' proposal that way. IMHO it would be better to stage it by first folding arch defconfigs into arch min/full and later if possible merge them in arch independent min/full ? ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hi everyone, > > > That's more of a question for Waldemar: does it really makes sense > > > to have defconfigs for each architecture? I mean how do they differ > > > between each other? > > > > > > For example, the ARC arcv2_defconfig and defconfig only differ by > > > the option CONFIG_ARC_CPU_HS, whose only purpose is to pass - > mcpu=archs. > > > Shouldn't be the solution used on ARM (removing all options to > > > select the compiler flags, and leave it to the user to pass the > > > appropriate > > > options) be used as well ? > > > > Yeah that would work fine I guess ! > > That means for building of our toolchain we'll need to have separately stored > "defconfigs" in some form. Let's see what Anton says on that :) > > And regardless of what mr Anton says having off-the-tree defconfigs is not > the best idea because with time options will go in and out and occasionally > we'll have outdated defconfigs. [AK] Not specifying architecture via uClibc config file is good for me - I wanted this long ago, since I never understood why current approach was used in the first place. Out-of-tree defconfigs are not good, because it is not clear who would update them in time. In addition that would create an additional coupling between toolchain build scripts and uClibc - they now should be always synchronized, which is a bad design. Defconfigs should be part of uClibc, toolchain build scripts (and other uClibc builders) would just select one by its name - less coupling, easier maintenance. IMHO it should be OK to increase capabilities of prebuilt toolchain, that Synopsys provides, to it would do more out of the box, at the expense of extra bloat - it is not possible to please everyone, anyway. Those users, who are not happy with "bloated" tools, can build tools themselves with configuration they need. That said, I think there should be some common sense in what are the features being enabled. I'd suggest that "full" feature configuration should enable those features which are required by at least one package in Buildroot or there is some another clearly defined user of it. If we don't know where feature is used - why enable it? Anton > > > > > > > So, are they really useful? Shouldn't uclibc-ng instead come with > > > just one or two defconfigs, like a "minimal" one and "full-featured" one? > > > > totally agree and I've historically been pushing back on patches from > > Alexey et all where we wanted to enable toggles to get buildroot packages > building. > > Those changes I made to make sure our prebuilt toolchain is useful for > building more packages. I.e. to be in one camp with Mentor's (AKA > CodeSourcery) prebuilt tools that are really capable. > > > That was > > a fair requirement on their part but it kept bloating uClibc for our > > typical embedded use. But this idea of minimal vs. full featured is exactly > what we need. > > @Alexey / @vlad can we take this up please ! > > Probably Waldemar's opinion might be useful here. > @Waldemar are there any plans for busting arch-specific defconfigs in favor > to generic defconfigs like those "minimal" and "full" mentioned above? > > -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs
On 03/01/2017 10:57 AM, Anton Kolesov wrote: >> That means for building of our toolchain we'll need to have separately stored >> "defconfigs" in some form. Let's see what Anton says on that :) But why is that - as long as buildroot (or other build systems) pass the right cpu flags - why do you need a seperate config ? >> And regardless of what mr Anton says having off-the-tree defconfigs is not >> the best idea because with time options will go in and out and occasionally >> we'll have outdated defconfigs. The whole out-of-tree defconfig approach is nonsense - lets not discuss it ! > [AK] Not specifying architecture via uClibc config file is good for me - I > wanted this long ago, since I never understood why current approach was used > in > the first place. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 03/20] asm-generic: Drop getrlimit and setrlimit syscalls from default list
The newer prlimit64 syscall provides all the functionality provided by the getrlimit and setrlimit syscalls and adds the pid of target process, so future architectures won't need to include getrlimit and setrlimit. Therefore drop getrlimit and setrlimit syscalls from the generic syscall list unless __ARCH_WANT_SET_GET_RLIMIT is defined by the architecture's unistd.h prior to including asm-generic/unistd.h, and adjust all architectures using the generic syscall list to define it so that no in-tree architectures are affected. Cc: Arnd Bergmann Cc: James Hogan Cc: linux-a...@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: Catalin Marinas Cc: Will Deacon Cc: linux-arm-ker...@lists.infradead.org Cc: Mark Salter Cc: Aurelien Jacquiot Cc: linux-c6x-...@linux-c6x.org Cc: Richard Kuo Cc: linux-hexa...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: Jonas Bonn Cc: li...@lists.openrisc.net Cc: Chen Liqin Cc: Lennox Wu Cc: Chris Metcalf Cc: Guan Xuetao Cc: Ley Foon Tan Cc: nios2-...@lists.rocketboards.org Cc: Yoshinori Sato Cc: uclinux-h8-de...@lists.sourceforge.jp Acked-by: Arnd Bergmann Acked-by: Mark Salter [c6x] Acked-by: James Hogan [metag] Acked-by: Ley Foon Tan [nios2] Acked-by: Stafford Horne [openrisc] Acked-by: Vineet Gupta #arch/arc bits Signed-off-by: Yury Norov --- arch/arc/include/uapi/asm/unistd.h | 1 + arch/arm64/include/uapi/asm/unistd.h | 1 + arch/c6x/include/uapi/asm/unistd.h | 1 + arch/h8300/include/uapi/asm/unistd.h | 1 + arch/hexagon/include/uapi/asm/unistd.h | 1 + arch/metag/include/uapi/asm/unistd.h | 1 + arch/nios2/include/uapi/asm/unistd.h | 1 + arch/openrisc/include/uapi/asm/unistd.h | 1 + arch/score/include/uapi/asm/unistd.h | 1 + arch/tile/include/uapi/asm/unistd.h | 1 + arch/unicore32/include/uapi/asm/unistd.h | 1 + include/uapi/asm-generic/unistd.h| 5 + 12 files changed, 16 insertions(+) diff --git a/arch/arc/include/uapi/asm/unistd.h b/arch/arc/include/uapi/asm/unistd.h index 9a34136..ac64965 100644 --- a/arch/arc/include/uapi/asm/unistd.h +++ b/arch/arc/include/uapi/asm/unistd.h @@ -16,6 +16,7 @@ #define _UAPI_ASM_ARC_UNISTD_H #define __ARCH_WANT_RENAMEAT +#define __ARCH_WANT_SET_GET_RLIMIT #define __ARCH_WANT_SYS_EXECVE #define __ARCH_WANT_SYS_CLONE #define __ARCH_WANT_SYS_VFORK diff --git a/arch/arm64/include/uapi/asm/unistd.h b/arch/arm64/include/uapi/asm/unistd.h index 043d17a..48355a6 100644 --- a/arch/arm64/include/uapi/asm/unistd.h +++ b/arch/arm64/include/uapi/asm/unistd.h @@ -15,5 +15,6 @@ */ #define __ARCH_WANT_RENAMEAT +#define __ARCH_WANT_SET_GET_RLIMIT #include diff --git a/arch/c6x/include/uapi/asm/unistd.h b/arch/c6x/include/uapi/asm/unistd.h index 12d73d9..f676231 100644 --- a/arch/c6x/include/uapi/asm/unistd.h +++ b/arch/c6x/include/uapi/asm/unistd.h @@ -15,6 +15,7 @@ */ #define __ARCH_WANT_RENAMEAT +#define __ARCH_WANT_SET_GET_RLIMIT #define __ARCH_WANT_SYS_CLONE /* Use the standard ABI for syscalls. */ diff --git a/arch/h8300/include/uapi/asm/unistd.h b/arch/h8300/include/uapi/asm/unistd.h index 7dd20ef..2f98394 100644 --- a/arch/h8300/include/uapi/asm/unistd.h +++ b/arch/h8300/include/uapi/asm/unistd.h @@ -1,5 +1,6 @@ #define __ARCH_NOMMU #define __ARCH_WANT_RENAMEAT +#define __ARCH_WANT_SET_GET_RLIMIT #include diff --git a/arch/hexagon/include/uapi/asm/unistd.h b/arch/hexagon/include/uapi/asm/unistd.h index 2151760..52d585c 100644 --- a/arch/hexagon/include/uapi/asm/unistd.h +++ b/arch/hexagon/include/uapi/asm/unistd.h @@ -28,6 +28,7 @@ #define sys_mmap2 sys_mmap_pgoff #define __ARCH_WANT_RENAMEAT +#define __ARCH_WANT_SET_GET_RLIMIT #define __ARCH_WANT_SYS_EXECVE #define __ARCH_WANT_SYS_CLONE #define __ARCH_WANT_SYS_VFORK diff --git a/arch/metag/include/uapi/asm/unistd.h b/arch/metag/include/uapi/asm/unistd.h index 459b6ec..16b5cb3 100644 --- a/arch/metag/include/uapi/asm/unistd.h +++ b/arch/metag/include/uapi/asm/unistd.h @@ -8,6 +8,7 @@ */ #define __ARCH_WANT_RENAMEAT +#define __ARCH_WANT_SET_GET_RLIMIT /* Use the standard ABI for syscalls. */ #include diff --git a/arch/nios2/include/uapi/asm/unistd.h b/arch/nios2/include/uapi/asm/unistd.h index 51a32c7..b0dda4d 100644 --- a/arch/nios2/include/uapi/asm/unistd.h +++ b/arch/nios2/include/uapi/asm/unistd.h @@ -18,6 +18,7 @@ #define sys_mmap2 sys_mmap_pgoff #define __ARCH_WANT_RENAMEAT +#define __ARCH_WANT_SET_GET_RLIMIT /* Use the standard ABI for syscalls */ #include diff --git a/arch/openrisc/include/uapi/asm/unistd.h b/arch/openrisc/include/uapi/asm/unistd.h index 471905b..6812d81 100644 --- a/arch/openrisc/include/uapi/asm/unistd.h +++ b/arch/openrisc/include/uapi/asm/unistd.h @@ -21,6 +21,7 @@ #define sys_mmap2 sys_mmap_pgoff #define __ARCH_WANT_RENAMEAT +#define __ARCH_WANT_SET_GET_RLIMIT #define __ARCH_WANT_SYS_FORK #define __ARCH_WANT_SYS_CLONE diff --git a/arch/score/include/uapi/asm/unistd.h b/arch/score/include/uapi/asm/unistd.
Re: [uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hi, Vineet Gupta wrote, > On 03/01/2017 10:57 AM, Anton Kolesov wrote: > >> That means for building of our toolchain we'll need to have separately > >> stored > >> "defconfigs" in some form. Let's see what Anton says on that :) > > But why is that - as long as buildroot (or other build systems) pass the > right cpu > flags - why do you need a seperate config ? > > >> And regardless of what mr Anton says having off-the-tree defconfigs is not > >> the best idea because with time options will go in and out and occasionally > >> we'll have outdated defconfigs. > > The whole out-of-tree defconfig approach is nonsense - lets not discuss it ! > > > [AK] Not specifying architecture via uClibc config file is good for me - I > > wanted this long ago, since I never understood why current approach was > > used in > > the first place. I am not really sure I understand the discussion completely. I think we discuss two points here. Point 1.: Rules.mak and some default CFLAGS/LDFLAGS passed to the compile and linking of code. I favour removing any specific -march/-mcpu/-mtune stuff, as we have done in the past for ARM/MIPS. So if ARC people like to remove this: ifeq ($(TARGET_ARCH),arc) CPU_CFLAGS-$(CONFIG_ARC_CPU_700) += -mA7 CPU_CFLAGS-$(CONFIG_ARC_CPU_HS) += -mcpu=archs CPU_LDFLAGS-y += $(CPU_CFLAGS) -marclinux endif I would say, yes, good thing. The toolchain defaults should be correctly set, no need to overwrite it inside uClibc-ng buildsystem. Point 2.: The files in extra/Configs/defconfigs/ and its use-cases. I haven't touched or used any files here, because most of them just contain TARGET_=y I would rather vote either to completely remove this directory or use it in the same way for all architectures. At the moment only ARC, OR1K and NDS32 use full defconfigs: wc -l uClibc-ng-git/extra/Configs/defconfigs/*/* 1 uClibc-ng-git/extra/Configs/defconfigs/alpha/defconfig 39 uClibc-ng-git/extra/Configs/defconfigs/arc/arcv2_defconfig 38 uClibc-ng-git/extra/Configs/defconfigs/arc/defconfig 38 uClibc-ng-git/extra/Configs/defconfigs/arc/tb10x_defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/arm/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/avr32/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/bfin/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/cris/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/frv/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/h8300/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/hppa/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/i386/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/ia64/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/m68k/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/metag/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/microblaze/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/mips/defconfig 167 uClibc-ng-git/extra/Configs/defconfigs/nds32/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/nios2/defconfig 236 uClibc-ng-git/extra/Configs/defconfigs/or1k/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/powerpc/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/sh/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/sparc/defconfig 1 uClibc-ng-git/extra/Configs/defconfigs/x86_64/defconfig 537 total I think only the ARC defconfigs are really used anywhere. All projects I know of, using uClibc-ng as a C library to create a cross-toolchain are using some kind of own defconfigs and generated fragments. In OpenADK I have some target//uclibc-ng.config for every architecture with sane defaults to regular run and test uClibc-ng based systems in emulators or on real hardware. This is used in embedded-test to do regression testing. Buildroot has some minimal defconfig and a developer can enable or disable some features (RPC, WCHAR, Locales, ..). I think a developer can also supply his own uClibc-ng config fragment. OpenWrt/LEDE use some own defconfigs. To have a good compatibility for a lot of applications the ARC Synopsis toolchains might use the existing Buildroot defaults, which allows to build a lot of software packages. We have seen before the last release, a lot of packages fail to compile, because the internal buildroot toolchain uses more features than the external Synopsis toolchain. (UCLIBC_HAS_GETPT, ..) If the default creates to big systems, Synopsis can use minimal configs and fix any autobuild issues ;) I think any external toolchain builders should create their own config and the uClibc-ng project should not provide any defconfigs anymore. Indeed when someone just use Kconfig defaults he/she should always end with a known to work toolchain. I still think we have too much different config possibilities and if we find some, which can be removed, I always vote for it. Best regards Waldemar ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org htt
Re: [uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hello, On Wed, 1 Mar 2017 18:25:35 +, Alexey Brodkin wrote: > That means for building of our toolchain we'll need to have > separately stored "defconfigs" in some form. Let's see what Anton says on > that :) > > And regardless of what mr Anton says having off-the-tree defconfigs is not > the best idea > because with time options will go in and out and occasionally we'll have > outdated > defconfigs. What would they be off-tree? What I meant is that when you look at the per architecture defconfigs, they are also all exactly the same, except for the TARGET_ option. So instead of having this big duplication, my suggestion is to get rid of architecture-specific defconfig, and just have a few architecture-independent defconfig, addressing common use cases (such as "minimal" and "feature full"). Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hi Thomas, On Wed, 2017-03-01 at 21:25 +0100, Thomas Petazzoni wrote: > Hello, > > On Wed, 1 Mar 2017 18:25:35 +, Alexey Brodkin wrote: > > > > > That means for building of our toolchain we'll need to have > > separately stored "defconfigs" in some form. Let's see what Anton says on > > that :) > > > > And regardless of what mr Anton says having off-the-tree defconfigs is not > > the best idea > > because with time options will go in and out and occasionally we'll have > > outdated > > defconfigs. > > What would they be off-tree? > > What I meant is that when you look at the per architecture defconfigs, > they are also all exactly the same, except for the TARGET_ option. > > So instead of having this big duplication, my suggestion is to get rid > of architecture-specific defconfig, and just have a few > architecture-independent defconfig, addressing common use cases (such > as "minimal" and "feature full"). That was exactly my understanding :) Speaking of "defconfigs" I really meant something that we may use for building our toolchain outside of Buildroot if we want something that differs from uClibc's defaults/defconfig - and most probably we'll need something either to add to uClibc's minimal_defconfig or exclude from _maximal_defconfig. Otherwise how may we be in control of libc in our "reference" toolchain? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs
Hello, On Wed, 1 Mar 2017 21:30:31 +, Alexey Brodkin wrote: > Speaking of "defconfigs" I really meant something that we may use > for building our toolchain outside of Buildroot if we want something that > differs from uClibc's defaults/defconfig - and most probably we'll need > something > either to add to uClibc's minimal_defconfig or exclude from > _maximal_defconfig. > > Otherwise how may we be in control of libc in our "reference" toolchain? A defconfig is what it is: a configuration provided as an example. Nothing forces you to use it. It's just an example. Buildroot doesn't use any of the uClibc-ng defconfigs. Buildroot has its own configuration for uClibc. You could just do the same for your reference toolchain. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
