All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH] toolchain: generate check-headers program under $(BUILD_DIR)
@ 2019-09-23  1:05 unixmania at gmail.com
  2019-09-23  8:38 ` yann.morin at orange.com
  0 siblings, 1 reply; 7+ messages in thread
From: unixmania at gmail.com @ 2019-09-23  1:05 UTC (permalink / raw)
  To: buildroot

From: Carlos Santos <unixmania@gmail.com>

Some installations mount /tmp with the 'noexec' option, which prevents
running the program generated there to check the kernel headers.

Avoid the problem by generating the program under $(BUILD_DIR), passed
as the first argument to check-kernel-headers.sh.

Fixes: https://bugs.busybox.net/show_bug.cgi?id=12241
---
CC: Cerem Cem ASLAN <ceremcem@ceremcem.net>
CC: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
 package/linux-headers/linux-headers.mk               |  1 +
 support/scripts/check-kernel-headers.sh              | 12 ++++++------
 toolchain/helpers.mk                                 |  9 ++++-----
 .../toolchain-external/pkg-toolchain-external.mk     |  1 +
 4 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/package/linux-headers/linux-headers.mk b/package/linux-headers/linux-headers.mk
index 46f270a0e1..676c8c44ea 100644
--- a/package/linux-headers/linux-headers.mk
+++ b/package/linux-headers/linux-headers.mk
@@ -133,6 +133,7 @@ endef
 ifeq ($(BR2_KERNEL_HEADERS_VERSION)$(BR2_KERNEL_HEADERS_AS_KERNEL)$(BR2_KERNEL_HEADERS_CUSTOM_TARBALL)$(BR2_KERNEL_HEADERS_CUSTOM_GIT),y)
 define LINUX_HEADERS_CHECK_VERSION
 	$(call check_kernel_headers_version,\
+		$(BUILD_DIR),\
 		$(STAGING_DIR),\
 		$(call qstrip,$(BR2_TOOLCHAIN_HEADERS_AT_LEAST)))
 endef
diff --git a/support/scripts/check-kernel-headers.sh b/support/scripts/check-kernel-headers.sh
index a8cca78b27..cbf71e0f23 100755
--- a/support/scripts/check-kernel-headers.sh
+++ b/support/scripts/check-kernel-headers.sh
@@ -1,14 +1,17 @@
 #!/bin/sh
 
-SYSROOT="${1}"
+BUILDDIR="${1}"
+SYSROOT="${2}"
 # Make sure we have enough version components
-HDR_VER="${2}.0.0"
+HDR_VER="${3}.0.0"
 
 HDR_M="${HDR_VER%%.*}"
 HDR_V="${HDR_VER#*.}"
 HDR_m="${HDR_V%%.*}"
 
-EXEC="$(mktemp -t check-headers.XXXXXX)"
+EXEC="$(mktemp -p "${BUILDDIR}" -t .check-headers.XXXXXX)"
+
+trap 'rm -f "${EXEC}"' EXIT
 
 # We do not want to account for the patch-level, since headers are
 # not supposed to change for different patchlevels, so we mask it out.
@@ -36,6 +39,3 @@ int main(int argc __attribute__((unused)),
 _EOF_
 
 "${EXEC}"
-ret=${?}
-rm -f "${EXEC}"
-exit ${ret}
diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk
index 86d945a5b1..6a4f7223c8 100644
--- a/toolchain/helpers.mk
+++ b/toolchain/helpers.mk
@@ -158,13 +158,12 @@ copy_toolchain_sysroot = \
 # Check the specified kernel headers version actually matches the
 # version in the toolchain.
 #
-# $1: sysroot directory
-# $2: kernel version string, in the form: X.Y
+# $1: build directory
+# $2: sysroot directory
+# $3: kernel version string, in the form: X.Y
 #
 check_kernel_headers_version = \
-	if ! support/scripts/check-kernel-headers.sh $(1) $(2); then \
-		exit 1; \
-	fi
+	support/scripts/check-kernel-headers.sh $(1) $(2) $(3)
 
 #
 # Check the specific gcc version actually matches the version in the
diff --git a/toolchain/toolchain-external/pkg-toolchain-external.mk b/toolchain/toolchain-external/pkg-toolchain-external.mk
index c3ddff263f..c00211d59c 100644
--- a/toolchain/toolchain-external/pkg-toolchain-external.mk
+++ b/toolchain/toolchain-external/pkg-toolchain-external.mk
@@ -531,6 +531,7 @@ define $(2)_CONFIGURE_CMDS
 	$$(Q)$$(call check_unusable_toolchain,$$(TOOLCHAIN_EXTERNAL_CC))
 	$$(Q)SYSROOT_DIR="$$(call toolchain_find_sysroot,$$(TOOLCHAIN_EXTERNAL_CC))" ; \
 	$$(call check_kernel_headers_version,\
+		$$(BUILD_DIR)\
 		$$(call toolchain_find_sysroot,$$(TOOLCHAIN_EXTERNAL_CC)),\
 		$$(call qstrip,$$(BR2_TOOLCHAIN_HEADERS_AT_LEAST))); \
 	$$(call check_gcc_version,$$(TOOLCHAIN_EXTERNAL_CC),\
-- 
2.18.1

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [Buildroot] [PATCH] toolchain: generate check-headers program under $(BUILD_DIR)
  2019-09-23  1:05 [Buildroot] [PATCH] toolchain: generate check-headers program under $(BUILD_DIR) unixmania at gmail.com
@ 2019-09-23  8:38 ` yann.morin at orange.com
  2019-09-23 11:17   ` Carlos Santos
  0 siblings, 1 reply; 7+ messages in thread
From: yann.morin at orange.com @ 2019-09-23  8:38 UTC (permalink / raw)
  To: buildroot

Carlos, All,

On 2019-09-22 22:05 -0300, unixmania at gmail.com spake thusly:
> From: Carlos Santos <unixmania@gmail.com>
> 
> Some installations mount /tmp with the 'noexec' option, which prevents
> running the program generated there to check the kernel headers.

I'm rather surprised that check-headers is the nly thing broken in that
case... :-/

Alternatively, we should probably use our own TMPDIR instead, which
would fix all such problems:

    diff --git a/Makefile b/Makefile
    index 82c844620a..a006149898 100644
    --- a/Makefile
    +++ b/Makefile
    @@ -209,6 +209,11 @@ BASE_TARGET_DIR := $(BASE_DIR)/target
     HOST_DIR := $(BASE_DIR)/host
     GRAPHS_DIR := $(BASE_DIR)/graphs
     
    +export TMPDIR = $(BUILD_DIR)/.br-temp-or-whatever
    +export TMP_DIR = $(TMPDIR)
    +export TEMP_DIR = $(TMPDIR)
    +# And so on...
    +
     LEGAL_INFO_DIR = $(BASE_DIR)/legal-info
     REDIST_SOURCES_DIR_TARGET = $(LEGAL_INFO_DIR)/sources
     REDIST_SOURCES_DIR_HOST = $(LEGAL_INFO_DIR)/host-sources
    @@ -1016,7 +1021,7 @@ savedefconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
     
     # staging and target directories do NOT list these as
     # dependencies anywhere else
    -$(BUILD_DIR) $(BASE_TARGET_DIR) $(HOST_DIR) $(BINARIES_DIR) $(LEGAL_INFO_DIR) $(REDIST_SOURCES_DIR_TARGET) $(REDIST_SOURCES_DIR_HOST):
    +$(BUILD_DIR) $(BASE_TARGET_DIR) $(HOST_DIR) $(BINARIES_DIR) $(LEGAL_INFO_DIR) $(REDIST_SOURCES_DIR_TARGET) $(REDIST_SOURCES_DIR_HOST) $(TMPDIR):
        @mkdir -p $@
     
     # outputmakefile generates a Makefile in the output directory, if using a

Doing smething like that would solve the issue globally, rather than
having ad-hoc solutions everywhere this will be needed.

> Avoid the problem by generating the program under $(BUILD_DIR), passed
> as the first argument to check-kernel-headers.sh.
> 
> Fixes: https://bugs.busybox.net/show_bug.cgi?id=12241
[--SNIP--]
> diff --git a/support/scripts/check-kernel-headers.sh b/support/scripts/check-kernel-headers.sh
> index a8cca78b27..cbf71e0f23 100755
> --- a/support/scripts/check-kernel-headers.sh
> +++ b/support/scripts/check-kernel-headers.sh
> @@ -1,14 +1,17 @@
>  #!/bin/sh
>  
> -SYSROOT="${1}"
> +BUILDDIR="${1}"
> +SYSROOT="${2}"
>  # Make sure we have enough version components
> -HDR_VER="${2}.0.0"
> +HDR_VER="${3}.0.0"
>  
>  HDR_M="${HDR_VER%%.*}"
>  HDR_V="${HDR_VER#*.}"
>  HDR_m="${HDR_V%%.*}"
>  
> -EXEC="$(mktemp -t check-headers.XXXXXX)"
> +EXEC="$(mktemp -p "${BUILDDIR}" -t .check-headers.XXXXXX)"
> +
> +trap 'rm -f "${EXEC}"' EXIT

Two things:

1. A trap on EXIT is a bashism, while this script uses /bin/sh, which
is not guaranteed to be bash.

2. Why do you want to use a trap on EXIT? If there is a motivation to do
so, it does not seem to be related to this change anyway, so should be
done in its own patch.

Regards,
Yann E. MORIN.

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
| +33 534.541.179 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
|      yann.morin (at) orange.com      |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Buildroot] [PATCH] toolchain: generate check-headers program under $(BUILD_DIR)
  2019-09-23  8:38 ` yann.morin at orange.com
@ 2019-09-23 11:17   ` Carlos Santos
  2019-09-23 11:48     ` Thomas Petazzoni
  2019-09-23 12:04     ` yann.morin at orange.com
  0 siblings, 2 replies; 7+ messages in thread
From: Carlos Santos @ 2019-09-23 11:17 UTC (permalink / raw)
  To: buildroot

On Mon, Sep 23, 2019 at 5:39 AM <yann.morin@orange.com> wrote:
>
> Carlos, All,
>
> On 2019-09-22 22:05 -0300, unixmania at gmail.com spake thusly:
> > From: Carlos Santos <unixmania@gmail.com>
> >
> > Some installations mount /tmp with the 'noexec' option, which prevents
> > running the program generated there to check the kernel headers.
>
> I'm rather surprised that check-headers is the nly thing broken in that
> case... :-/
>
> Alternatively, we should probably use our own TMPDIR instead, which
> would fix all such problems:
>
>     diff --git a/Makefile b/Makefile
>     index 82c844620a..a006149898 100644
>     --- a/Makefile
>     +++ b/Makefile
>     @@ -209,6 +209,11 @@ BASE_TARGET_DIR := $(BASE_DIR)/target
>      HOST_DIR := $(BASE_DIR)/host
>      GRAPHS_DIR := $(BASE_DIR)/graphs
>
>     +export TMPDIR = $(BUILD_DIR)/.br-temp-or-whatever
>     +export TMP_DIR = $(TMPDIR)
>     +export TEMP_DIR = $(TMPDIR)
>     +# And so on...

That would create all temporary files under
$(BUILD_DIR)/.br-temp-or-whatever, ruining the advantage of using a
tmpfs mounted at /tmp, which is much faster because it's in RAM.

>      LEGAL_INFO_DIR = $(BASE_DIR)/legal-info
>      REDIST_SOURCES_DIR_TARGET = $(LEGAL_INFO_DIR)/sources
>      REDIST_SOURCES_DIR_HOST = $(LEGAL_INFO_DIR)/host-sources
>     @@ -1016,7 +1021,7 @@ savedefconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
>
>      # staging and target directories do NOT list these as
>      # dependencies anywhere else
>     -$(BUILD_DIR) $(BASE_TARGET_DIR) $(HOST_DIR) $(BINARIES_DIR) $(LEGAL_INFO_DIR) $(REDIST_SOURCES_DIR_TARGET) $(REDIST_SOURCES_DIR_HOST):
>     +$(BUILD_DIR) $(BASE_TARGET_DIR) $(HOST_DIR) $(BINARIES_DIR) $(LEGAL_INFO_DIR) $(REDIST_SOURCES_DIR_TARGET) $(REDIST_SOURCES_DIR_HOST) $(TMPDIR):
>         @mkdir -p $@
>
>      # outputmakefile generates a Makefile in the output directory, if using a
>
> Doing smething like that would solve the issue globally, rather than
> having ad-hoc solutions everywhere this will be needed.
>
> > Avoid the problem by generating the program under $(BUILD_DIR), passed
> > as the first argument to check-kernel-headers.sh.
> >
> > Fixes: https://bugs.busybox.net/show_bug.cgi?id=12241
> [--SNIP--]
> > diff --git a/support/scripts/check-kernel-headers.sh b/support/scripts/check-kernel-headers.sh
> > index a8cca78b27..cbf71e0f23 100755
> > --- a/support/scripts/check-kernel-headers.sh
> > +++ b/support/scripts/check-kernel-headers.sh
> > @@ -1,14 +1,17 @@
> >  #!/bin/sh
> >
> > -SYSROOT="${1}"
> > +BUILDDIR="${1}"
> > +SYSROOT="${2}"
> >  # Make sure we have enough version components
> > -HDR_VER="${2}.0.0"
> > +HDR_VER="${3}.0.0"
> >
> >  HDR_M="${HDR_VER%%.*}"
> >  HDR_V="${HDR_VER#*.}"
> >  HDR_m="${HDR_V%%.*}"
> >
> > -EXEC="$(mktemp -t check-headers.XXXXXX)"
> > +EXEC="$(mktemp -p "${BUILDDIR}" -t .check-headers.XXXXXX)"
> > +
> > +trap 'rm -f "${EXEC}"' EXIT
>
> Two things:
>
> 1. A trap on EXIT is a bashism, while this script uses /bin/sh, which
> is not guaranteed to be bash.

From the IEEE Std 1003.1, 2004 Edition
(https://pubs.opengroup.org/onlinepubs/009695399/utilities/trap.html):

"The condition can be EXIT, 0 (equivalent to EXIT), or a signal
specified using a symbolic name, without the SIG prefix [...]"

> 2. Why do you want to use a trap on EXIT? If there is a motivation to do
> so, it does not seem to be related to this change anyway, so should be
> done in its own patch.

It's a cleaner solution.

-- 
Carlos Santos <unixmania@gmail.com>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Buildroot] [PATCH] toolchain: generate check-headers program under $(BUILD_DIR)
  2019-09-23 11:17   ` Carlos Santos
@ 2019-09-23 11:48     ` Thomas Petazzoni
  2019-09-23 12:04     ` yann.morin at orange.com
  1 sibling, 0 replies; 7+ messages in thread
From: Thomas Petazzoni @ 2019-09-23 11:48 UTC (permalink / raw)
  To: buildroot

On Mon, 23 Sep 2019 08:17:55 -0300
Carlos Santos <unixmania@gmail.com> wrote:

> > I'm rather surprised that check-headers is the nly thing broken in that
> > case... :-/
> >
> > Alternatively, we should probably use our own TMPDIR instead, which
> > would fix all such problems:
> >
> >     diff --git a/Makefile b/Makefile
> >     index 82c844620a..a006149898 100644
> >     --- a/Makefile
> >     +++ b/Makefile
> >     @@ -209,6 +209,11 @@ BASE_TARGET_DIR := $(BASE_DIR)/target
> >      HOST_DIR := $(BASE_DIR)/host
> >      GRAPHS_DIR := $(BASE_DIR)/graphs
> >
> >     +export TMPDIR = $(BUILD_DIR)/.br-temp-or-whatever
> >     +export TMP_DIR = $(TMPDIR)
> >     +export TEMP_DIR = $(TMPDIR)
> >     +# And so on...  
> 
> That would create all temporary files under
> $(BUILD_DIR)/.br-temp-or-whatever, ruining the advantage of using a
> tmpfs mounted at /tmp, which is much faster because it's in RAM.

The problem indeed only occurs with temporary files that need to be
*executed*. For example, gcc creates tons of temporary files in /tmp,
and that works perfectly fine and shouldn't be changed. So at this
point, I also tend to prefer Carlos solution to only address the
check-headers case.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Buildroot] [PATCH] toolchain: generate check-headers program under $(BUILD_DIR)
  2019-09-23 11:17   ` Carlos Santos
  2019-09-23 11:48     ` Thomas Petazzoni
@ 2019-09-23 12:04     ` yann.morin at orange.com
  2019-09-23 12:08       ` Thomas Petazzoni
  2019-09-23 12:19       ` Carlos Santos
  1 sibling, 2 replies; 7+ messages in thread
From: yann.morin at orange.com @ 2019-09-23 12:04 UTC (permalink / raw)
  To: buildroot

Carlos, All,

On 2019-09-23 08:17 -0300, Carlos Santos spake thusly:
> On Mon, Sep 23, 2019 at 5:39 AM <yann.morin@orange.com> wrote:
> > On 2019-09-22 22:05 -0300, unixmania at gmail.com spake thusly:
> > > From: Carlos Santos <unixmania@gmail.com>
> > >
> > > Some installations mount /tmp with the 'noexec' option, which prevents
> > > running the program generated there to check the kernel headers.
> >
> > I'm rather surprised that check-headers is the nly thing broken in that
> > case... :-/
> >
> > Alternatively, we should probably use our own TMPDIR instead, which
> > would fix all such problems:
> >
> >     diff --git a/Makefile b/Makefile
> >     index 82c844620a..a006149898 100644
> >     --- a/Makefile
> >     +++ b/Makefile
> >     @@ -209,6 +209,11 @@ BASE_TARGET_DIR := $(BASE_DIR)/target
> >      HOST_DIR := $(BASE_DIR)/host
> >      GRAPHS_DIR := $(BASE_DIR)/graphs
> >
> >     +export TMPDIR = $(BUILD_DIR)/.br-temp-or-whatever
> >     +export TMP_DIR = $(TMPDIR)
> >     +export TEMP_DIR = $(TMPDIR)
> >     +# And so on...
> 
> That would create all temporary files under
> $(BUILD_DIR)/.br-temp-or-whatever, ruining the advantage of using a
> tmpfs mounted at /tmp, which is much faster because it's in RAM.

I don't know what distro mounts /tmp as a tmpfs by default. It is
certainly not the case on my Ubuntu, or on Debian when I last installed
one...

But yes, having all temp files in $(BUILD_DIR)/.br-temp-or-whatever
would be the expected behaviour.

What I'm afraid of, is that there are (a lot of) packages that do a
similar thing, and we would have to fix each of those individually.
Setting a global TMPDIR would fix it once and for all.

Also, I tend to see a lot of left-over temp files in /tmp, even after a
build is completed, because pacakges buildsystems often forget to
cleanup properly behind them, which would eventually fill /tmp on a
long-running machine like a build server. Having our own temp dir would
mean it actually gets cleaned when the build dir is removed.

And anyway, for short-lived temp files, the 'slowness' is probably a
false reason: the short-lived temp files will probably never actually
hit the HDD (or SSD), and will only ever live in the kernel cache. And
if they happen to be a bit longer-lived that they do hit torage, then
they'd also probably undergo a round of IO scheduling, which will most
probably postpone the actual write to long after the file is actually
closed.

But I would very like to have actual numbers to prove either way.

(Doing the whole build under tmpfs is another topic, and that would
probably provide an actual, measurable gain.)

There is a third alternative. Stash the following somewhere early in the
build process (e.g. in check-dependencies or some such):

    if ! is_mounted_with_exec "${TMPDIR:-/tmp}"; then
        printf '%s is mounted with noexec; this is not gonna fly.\n' "${TMPDIR:-/tmp}"
        exit 1
    fi

> > 1. A trap on EXIT is a bashism, while this script uses /bin/sh, which
> > is not guaranteed to be bash.
> 
> From the IEEE Std 1003.1, 2004 Edition
> (https://pubs.opengroup.org/onlinepubs/009695399/utilities/trap.html):
> 
> "The condition can be EXIT, 0 (equivalent to EXIT), or a signal
> specified using a symbolic name, without the SIG prefix [...]"

Ah, right. It's ERR that is a bashism, my bad.

> > 2. Why do you want to use a trap on EXIT? If there is a motivation to do
> > so, it does not seem to be related to this change anyway, so should be
> > done in its own patch.
> 
> It's a cleaner solution.

How is it cleaner? I would even argue that it is no longer obvious that
some code is actually run at the end...

The only case where I think a trap is interesting, IMHO, is when we
want to catch errors. But as this script is not 'set -e', it will
always go through to the end, and thus all commands in the script will
be executed.

But for a simple script like that, I fail to see the added value of a
trap on EXIT...

And even though, we would want to have that in a separate patch, because
it is unrelated to what the patch is initially trying to fix.

Regards,
Yann E. MORIN.

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
| +33 534.541.179 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
|      yann.morin (at) orange.com      |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Buildroot] [PATCH] toolchain: generate check-headers program under $(BUILD_DIR)
  2019-09-23 12:04     ` yann.morin at orange.com
@ 2019-09-23 12:08       ` Thomas Petazzoni
  2019-09-23 12:19       ` Carlos Santos
  1 sibling, 0 replies; 7+ messages in thread
From: Thomas Petazzoni @ 2019-09-23 12:08 UTC (permalink / raw)
  To: buildroot

On Mon, 23 Sep 2019 14:04:48 +0200
<yann.morin@orange.com> wrote:

> I don't know what distro mounts /tmp as a tmpfs by default. It is
> certainly not the case on my Ubuntu, or on Debian when I last installed
> one...

$ mount | grep "/tmp"
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)

Regular Fedora 30 installation.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Buildroot] [PATCH] toolchain: generate check-headers program under $(BUILD_DIR)
  2019-09-23 12:04     ` yann.morin at orange.com
  2019-09-23 12:08       ` Thomas Petazzoni
@ 2019-09-23 12:19       ` Carlos Santos
  1 sibling, 0 replies; 7+ messages in thread
From: Carlos Santos @ 2019-09-23 12:19 UTC (permalink / raw)
  To: buildroot

On Mon, Sep 23, 2019 at 9:05 AM <yann.morin@orange.com> wrote:
>
> Carlos, All,
>
> On 2019-09-23 08:17 -0300, Carlos Santos spake thusly:
> > On Mon, Sep 23, 2019 at 5:39 AM <yann.morin@orange.com> wrote:
> > > On 2019-09-22 22:05 -0300, unixmania at gmail.com spake thusly:
> > > > From: Carlos Santos <unixmania@gmail.com>
> > > >
> > > > Some installations mount /tmp with the 'noexec' option, which prevents
> > > > running the program generated there to check the kernel headers.
> > >
> > > I'm rather surprised that check-headers is the nly thing broken in that
> > > case... :-/
> > >
> > > Alternatively, we should probably use our own TMPDIR instead, which
> > > would fix all such problems:
> > >
> > >     diff --git a/Makefile b/Makefile
> > >     index 82c844620a..a006149898 100644
> > >     --- a/Makefile
> > >     +++ b/Makefile
> > >     @@ -209,6 +209,11 @@ BASE_TARGET_DIR := $(BASE_DIR)/target
> > >      HOST_DIR := $(BASE_DIR)/host
> > >      GRAPHS_DIR := $(BASE_DIR)/graphs
> > >
> > >     +export TMPDIR = $(BUILD_DIR)/.br-temp-or-whatever
> > >     +export TMP_DIR = $(TMPDIR)
> > >     +export TEMP_DIR = $(TMPDIR)
> > >     +# And so on...
> >
> > That would create all temporary files under
> > $(BUILD_DIR)/.br-temp-or-whatever, ruining the advantage of using a
> > tmpfs mounted at /tmp, which is much faster because it's in RAM.
>
> I don't know what distro mounts /tmp as a tmpfs by default. It is
> certainly not the case on my Ubuntu, or on Debian when I last installed
> one...
>
> But yes, having all temp files in $(BUILD_DIR)/.br-temp-or-whatever
> would be the expected behaviour.
>
> What I'm afraid of, is that there are (a lot of) packages that do a
> similar thing, and we would have to fix each of those individually.
> Setting a global TMPDIR would fix it once and for all.
>
> Also, I tend to see a lot of left-over temp files in /tmp, even after a
> build is completed, because pacakges buildsystems often forget to
> cleanup properly behind them, which would eventually fill /tmp on a
> long-running machine like a build server. Having our own temp dir would
> mean it actually gets cleaned when the build dir is removed.
>
> And anyway, for short-lived temp files, the 'slowness' is probably a
> false reason: the short-lived temp files will probably never actually
> hit the HDD (or SSD), and will only ever live in the kernel cache. And
> if they happen to be a bit longer-lived that they do hit torage, then
> they'd also probably undergo a round of IO scheduling, which will most
> probably postpone the actual write to long after the file is actually
> closed.
>
> But I would very like to have actual numbers to prove either way.
>
> (Doing the whole build under tmpfs is another topic, and that would
> probably provide an actual, measurable gain.)
>
> There is a third alternative. Stash the following somewhere early in the
> build process (e.g. in check-dependencies or some such):
>
>     if ! is_mounted_with_exec "${TMPDIR:-/tmp}"; then
>         printf '%s is mounted with noexec; this is not gonna fly.\n' "${TMPDIR:-/tmp}"
>         exit 1
>     fi
>
> > > 1. A trap on EXIT is a bashism, while this script uses /bin/sh, which
> > > is not guaranteed to be bash.
> >
> > From the IEEE Std 1003.1, 2004 Edition
> > (https://pubs.opengroup.org/onlinepubs/009695399/utilities/trap.html):
> >
> > "The condition can be EXIT, 0 (equivalent to EXIT), or a signal
> > specified using a symbolic name, without the SIG prefix [...]"
>
> Ah, right. It's ERR that is a bashism, my bad.
>
> > > 2. Why do you want to use a trap on EXIT? If there is a motivation to do
> > > so, it does not seem to be related to this change anyway, so should be
> > > done in its own patch.
> >
> > It's a cleaner solution.
>
> How is it cleaner? I would even argue that it is no longer obvious that
> some code is actually run at the end...
>
> The only case where I think a trap is interesting, IMHO, is when we
> want to catch errors. But as this script is not 'set -e', it will
> always go through to the end, and thus all commands in the script will
> be executed.
>
> But for a simple script like that, I fail to see the added value of a
> trap on EXIT...
>
> And even though, we would want to have that in a separate patch, because
> it is unrelated to what the patch is initially trying to fix.
>
> Regards,
> Yann E. MORIN.
>
> --
>                                         ____________
> .-----------------.--------------------:       _    :------------------.
> |  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
> | +33 534.541.179 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
> | +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
> |      yann.morin (at) orange.com      |_="    ,--' | / \ HTML MAIL    |
> '--------------------------------------:______/_____:------------------'
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>

Sorry, I prefer to spend my time doing things instead of arguing about
them. Go ahead and do it as you want.

-- 
Carlos Santos <unixmania@gmail.com>

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2019-09-23 12:19 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-23  1:05 [Buildroot] [PATCH] toolchain: generate check-headers program under $(BUILD_DIR) unixmania at gmail.com
2019-09-23  8:38 ` yann.morin at orange.com
2019-09-23 11:17   ` Carlos Santos
2019-09-23 11:48     ` Thomas Petazzoni
2019-09-23 12:04     ` yann.morin at orange.com
2019-09-23 12:08       ` Thomas Petazzoni
2019-09-23 12:19       ` Carlos Santos

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.