[Buildroot] [PATCH] util-linux: disable fallocate for avr32

[Buildroot] [PATCH] util-linux: disable fallocate for avr32

[spdawson at gmail.com]

From: Simon Dawson <spdawson@gmail.com>

The fallocate syscall is not implemented in the avr32 toolchain.

Fixes build failures such as the following.

  http://autobuild.buildroot.net/results/bc4/bc41a3fea20181526eb247ac910244aa2aa4c4c0/

Signed-off-by: Simon Dawson <spdawson@gmail.com>
---
 package/util-linux/Config.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/util-linux/Config.in b/package/util-linux/Config.in
index 41e0986..d56e631 100644
--- a/package/util-linux/Config.in
+++ b/package/util-linux/Config.in
@@ -72,6 +72,7 @@ config BR2_PACKAGE_UTIL_LINUX_EJECT
 
 config BR2_PACKAGE_UTIL_LINUX_FALLOCATE
 	bool "fallocate"
+	depends on !BR2_avr32 # fallocate not implemented
 	help
 	  Preallocate space to a file
 
-- 
1.8.3.2

[Buildroot] [PATCH] util-linux: disable fallocate for avr32

[Thomas Petazzoni]

Simon,

On Sun,  3 Nov 2013 09:56:25 +0000, spdawson at gmail.com wrote:
> From: Simon Dawson <spdawson@gmail.com>
> 
> The fallocate syscall is not implemented in the avr32 toolchain.
> 
> Fixes build failures such as the following.
> 
>   http://autobuild.buildroot.net/results/bc4/bc41a3fea20181526eb247ac910244aa2aa4c4c0/
> 
> Signed-off-by: Simon Dawson <spdawson@gmail.com>
> ---
>  package/util-linux/Config.in | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/package/util-linux/Config.in b/package/util-linux/Config.in
> index 41e0986..d56e631 100644
> --- a/package/util-linux/Config.in
> +++ b/package/util-linux/Config.in
> @@ -72,6 +72,7 @@ config BR2_PACKAGE_UTIL_LINUX_EJECT
>  
>  config BR2_PACKAGE_UTIL_LINUX_FALLOCATE
>  	bool "fallocate"
> +	depends on !BR2_avr32 # fallocate not implemented
>  	help
>  	  Preallocate space to a file
>  

Situation is a bit fuzzy here.

We have added a patch to uClibc that implements fallocate support:
package/uclibc/0.9.33.2/uclibc-0041-libc-add-posix_fallocate.patch. So
internal toolchains based on 0.9.33.2 should now have fallocate support.

However:

 * The AVR32 toolchain used in the autobuilders predates the addition
   of this patch, and therefore does not have the fallocate support
   (the autobuilders uses a Buildroot generated toolchain, but
   generated with Buildroot 2013.05).

 * The AVR32 support at the moment is using 0.9.33.2, but you told us
   that 0.9.33.2 is basically not working properly on AVR32, and that
   reverting to 0.9.31 was the only solution to get a working AVR32
   system. This would indeed mean that fallocate support would not be
   available on AVR32 (but it would more be related to the uClibc
   version rather than the architecture).

 * A larger problem that I have already raised several times is that
   adding feature patches to the uClibc package in Buildroot is causing
   issues with external toolchain support for uClibc toolchains. These
   external toolchains are very unlikely to carry the same backported
   feature patches as we do, and therefore the build will break with
   those external toolchains if Buildroot relies on uClibc having those
   features.

I'm Cc'ing Arnout, Peter, Yann and Thomas DS on this one, because we
really need to define a policy on this topic.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] util-linux: disable fallocate for avr32

[Yann E. MORIN]

Simon, Thomas, All,

On 2013-11-03 11:34 +0100, Thomas Petazzoni spake thusly:
> On Sun,  3 Nov 2013 09:56:25 +0000, spdawson at gmail.com wrote:
> > From: Simon Dawson <spdawson@gmail.com>
> > 
> > The fallocate syscall is not implemented in the avr32 toolchain.
> > 
> > Fixes build failures such as the following.
> > 
> >   http://autobuild.buildroot.net/results/bc4/bc41a3fea20181526eb247ac910244aa2aa4c4c0/
> > 
> > Signed-off-by: Simon Dawson <spdawson@gmail.com>
> > ---
> >  package/util-linux/Config.in | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/package/util-linux/Config.in b/package/util-linux/Config.in
> > index 41e0986..d56e631 100644
> > --- a/package/util-linux/Config.in
> > +++ b/package/util-linux/Config.in
> > @@ -72,6 +72,7 @@ config BR2_PACKAGE_UTIL_LINUX_EJECT
> >  
> >  config BR2_PACKAGE_UTIL_LINUX_FALLOCATE
> >  	bool "fallocate"
> > +	depends on !BR2_avr32 # fallocate not implemented
> >  	help
> >  	  Preallocate space to a file
> >  
> 
> Situation is a bit fuzzy here.
> 
> We have added a patch to uClibc that implements fallocate support:
> package/uclibc/0.9.33.2/uclibc-0041-libc-add-posix_fallocate.patch. So
> internal toolchains based on 0.9.33.2 should now have fallocate support.
> 
> However:
> 
>  * The AVR32 toolchain used in the autobuilders predates the addition
>    of this patch, and therefore does not have the fallocate support
>    (the autobuilders uses a Buildroot generated toolchain, but
>    generated with Buildroot 2013.05).
> 
>  * The AVR32 support at the moment is using 0.9.33.2, but you told us
>    that 0.9.33.2 is basically not working properly on AVR32, and that
>    reverting to 0.9.31 was the only solution to get a working AVR32
>    system. This would indeed mean that fallocate support would not be
>    available on AVR32 (but it would more be related to the uClibc
>    version rather than the architecture).
> 
>  * A larger problem that I have already raised several times is that
>    adding feature patches to the uClibc package in Buildroot is causing
>    issues with external toolchain support for uClibc toolchains. These
>    external toolchains are very unlikely to carry the same backported
>    feature patches as we do, and therefore the build will break with
>    those external toolchains if Buildroot relies on uClibc having those
>    features.
> 
> I'm Cc'ing Arnout, Peter, Yann and Thomas DS on this one, because we
> really need to define a policy on this topic.

Our stance has always been 'no feature-patch in Buildroot'.
OTOH, I can understand that fallocate is really required (being in
POSIX).

But since uClibc is highly configurable, it could happen that an
external toolchain would have fallocate disabled (being in Advanced
RT in POSIX).

So, I'm a bit fuzzy as to what we should do here.

The best approach would be to push all of our changes upstream uClibc,
and hope for a release soon, so we can bump. But it looks like upstream
is not really alive those days.

Another approach would be to add yet one more toolchain knob that tells
whether the toolchain has fallocate (defaults to 'y' for (e)glibc and
internal, prompts for external uClibc).

My preference would be to remove feature-patches, but that is really
gonna hurt newcomers (and may bite long-timers as well).

In the end, I'm not much of any help on that one, sorry... :-(

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] util-linux: disable fallocate for avr32

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Sun, 3 Nov 2013 12:06:13 +0100, Yann E. MORIN wrote:

> > I'm Cc'ing Arnout, Peter, Yann and Thomas DS on this one, because we
> > really need to define a policy on this topic.
> 
> Our stance has always been 'no feature-patch in Buildroot'.
> OTOH, I can understand that fallocate is really required (being in
> POSIX).
> 
> But since uClibc is highly configurable, it could happen that an
> external toolchain would have fallocate disabled (being in Advanced
> RT in POSIX).

True, but our position on the matter has more or less always been: the
external uClibc toolchain should have a uClibc configuration similar to
the one we have in Buildroot. We cannot support any random uClibc
configuration.

But it's hard to require external toolchains to have uClibc features
that are not even part of a uClibc stable release.

> So, I'm a bit fuzzy as to what we should do here.
> 
> The best approach would be to push all of our changes upstream uClibc,
> and hope for a release soon, so we can bump. But it looks like upstream
> is not really alive those days.

All the feature patches we have for uClibc are already upstream: they
are precisely backported from upstream... waiting for an upstream
release to occur.

> Another approach would be to add yet one more toolchain knob that tells
> whether the toolchain has fallocate (defaults to 'y' for (e)glibc and
> internal, prompts for external uClibc).

True, but that doesn't scale really nicely to the crazy number of
features. For example, systemd needs execvpe(), which is not in uClibc
0.9.33, but is available in our uClibc thanks to a backported patch.
Should we also add another config know for execvpe() ?

> My preference would be to remove feature-patches, but that is really
> gonna hurt newcomers (and may bite long-timers as well).

I believe the only reasonable solutions are (alternatively, and the
choice can be made differently per-package) :

 (1) Add patches to the package to avoid usage of unimplemented uClibc
     features (when possible)

 (2) Mark the packages as depends on !UCLIBC

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] util-linux: disable fallocate for avr32

[Arnout Vandecappelle]

On 03/11/13 12:17, Thomas Petazzoni wrote:
> Dear Yann E. MORIN,
>
> On Sun, 3 Nov 2013 12:06:13 +0100, Yann E. MORIN wrote:
>
[snip]
>> My preference would be to remove feature-patches, but that is really
>> gonna hurt newcomers (and may bite long-timers as well).
>
> I believe the only reasonable solutions are (alternatively, and the
> choice can be made differently per-package) :
>
>   (1) Add patches to the package to avoid usage of unimplemented uClibc
>       features (when possible)
>
>   (2) Mark the packages as depends on !UCLIBC

  If I may throw in yet another alternative: depend on a version of 
uClibc. We can call our patched uClibc version 0.9.34. At least, this 
still applies when there's a finally a uClibc release: we would then need 
a mechanism to mark a package to depend on the new uClibc.

  On second thought, this is probably still difficult to maintain and 
equally difficult for user to use a buildroot-generated toolchain as an 
external toolchain.

  Regards,
  Arnout

>
> 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] util-linux: disable fallocate for avr32

[Peter Korsgaard]

>>>>> "spdawson" == spdawson  <spdawson@gmail.com> writes:

> From: Simon Dawson <spdawson@gmail.com>
> The fallocate syscall is not implemented in the avr32 toolchain.

> Fixes build failures such as the following.

>   http://autobuild.buildroot.net/results/bc4/bc41a3fea20181526eb247ac910244aa2aa4c4c0/

Committed, thanks.

-- 
Bye, Peter Korsgaard