From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6566568349648551936 X-Received: by 2002:adf:f011:: with SMTP id j17-v6mr120363wro.31.1528966300685; Thu, 14 Jun 2018 01:51:40 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:7c18:: with SMTP id x24-v6ls1562008wmc.2.gmail; Thu, 14 Jun 2018 01:51:40 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKPiT9HRbLlRvoQyiRSUTTQagYcXZG/qhG1vhaRiUpPt5Yv7ZfA2LwefuwnazOdSj/91xKC X-Received: by 2002:a1c:e907:: with SMTP id q7-v6mr110476wmc.3.1528966300150; Thu, 14 Jun 2018 01:51:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528966300; cv=none; d=google.com; s=arc-20160816; b=KSNTYpcelhd/yVf1O/1X8A6jvfMUhAA/r3famQSWx6nuczAWIVZE86LbH5o8S94gu5 t5W23RsEDiTXPOcNIZoVSDoj7CGV8dj83/NrKHGlHqaLl77i82Xr+5w3gtXv+VKGUBdg QLaQ7uieD77pjdeyr3J22lzvkPwWyeHjF/o/sB5mnSLzyBcImYOmX6TxNi6nv3ogrjWd zHXaFHBBbw2f0c/HxxWjd82WWYSNAs/a3+dP1/YBtl5d9n8X0ge43/ExOfW9il0wySqG lqD7CWelr+PUs3J+mOAucreOd4w8W7yHPfk2JNl3reyOxGNz4gvv9smepO2xEm1HTrUc gCdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :arc-authentication-results; bh=NLWnEX10pXuHL0aZS1plJBLzT01pAJRVUipRO3r7WEw=; b=zwpOxDWcbIcZWevvZxdD41mZafXkU35e7WQWSDhno/m4Abv+Qbb+I1kaoJneXPn5qw e+uZnvCGnMunTTeIbl6ZxEfLkTlIsVbd7NI+iczCQBlk03Q1VpPIDWwgnhomPwgTJTDO ixQ7uFfHTaDi5d2HTdlKtkOLeu8zP1w2oLD94zLgyu4+MPSQqZY4vUtW1GfkGwes6jGv SdETiMn2Fiid7/ZCVEqg20JDAJbEerwR1lmG+LlFum+xRpFOP6HmHSC+nnWkklNAVTR4 AaSc00rbaAWVwBMmawNNDa6UpSewRxWyqjf2tEsGiZpmb8BrKW8UFpUsV8h9Me4R48Od 6uqw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id x21-v6si53170wmh.3.2018.06.14.01.51.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jun 2018 01:51:40 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w5E8pddL015641 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Jun 2018 10:51:39 +0200 Received: from [167.87.53.194] ([167.87.53.194]) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id w5E8pdBh026459; Thu, 14 Jun 2018 10:51:39 +0200 Subject: Re: [RFC PATCH 0/6] ISAR SDK root filesystem To: "[ext] Henning Schild" , "Maxim Yu. Osipov" Cc: isar-users@googlegroups.com References: <20180613135829.3151-1-mosipov@ilbers.de> <20180614104826.0d954ed7@md1pvb1c.ad001.siemens.net> From: Jan Kiszka Message-ID: <52c0c6db-ca7e-87a3-c471-d247f4118584@siemens.com> Date: Thu, 14 Jun 2018 10:51:39 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <20180614104826.0d954ed7@md1pvb1c.ad001.siemens.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: YPon9wTD+17L On 2018-06-14 10:48, [ext] Henning Schild wrote: > Am Wed, 13 Jun 2018 15:58:23 +0200 > schrieb "Maxim Yu. Osipov" : > >> Hello everybody, >> >> This series provides preliminary support of ISAR SDK root file system. >> >> Motivation >> >> Building applications for targets in ISAR takes a lot of time as they >> are built under QEMU. SDK providing crossbuild environment will help >> to solve this problem. >> >> Approach >> >> Create SDK root file system for host with installed cross-toolchain >> for target architecture and ability to install already prebuilt >> target binary artifacts. Developer chroots to sdk rootfs and develops >> applications for target platform. >> >> Solution >> >> User manually triggers creation of SDK root filesystem for his target >> platform by launching the task `do_isar_sdk` for target image, f.e. >> `bitbake -c do_isar_sdk >> multiconfig:${MACHINE}-${DISTRO}:isar-image-base`. >> >> The resulting SDK rootfs is located under >> `tmp/work/${DITSRO}-${DISTRO_ARCH}/sdkchroot/rootfs`. SDK rootfs >> directory `/isar-apt` contains the copy of isar-apt repo with locally >> prebuilt target debian packages. One may chroot to SDK and install >> required target packages with the help of `apt-get install >> :` command. >> >> Limitation >> >> Only Debian Stretch for SDK root filesystem is supported as only >> Stretch provides crossbuild environment by default. (Debian Jessie >> requires some additional preconfiguration steps see >> https://wiki.debian.org/CrossToolchains#Installation for details). > > Are we ready for buster? Not many people care about the past, but let > us make sure this will work in the future. > >> Example >> >> - Trigger creation of SDK root filesystem >> >> >> bitbake -c do_isar_sdk multiconfig:qemuarm-stretch:isar-image-base >> >> >> - Mount the following directories in chroot by passing resulting >> rootfs as an argument to the script `mount_chroot.sh`: >> >> >> $ cat mount_chroot.sh >> #!/bin/bash >> sudo mount /tmp $1/tmp -o bind >> sudo mount proc $1/proc -t proc -o nosuid,noexec,nodev >> sudo mount sysfs $1/sys -t sysfs -o nosuid,noexec,nodev >> sudo mount devtmpfs $1/dev -t devtmpfs -o mode=0755,nosuid >> sudo mount devpts $1/dev/pts -t devpts -o gid=5,mode=620 >> sudo mount tmpfs $1/dev/shm -t tmpfs -o rw,seclabel,nosuid,nodev >> >> $ ./mount_chroot.sh ./build/tmp/work/debian-stretch-armhf/sdkchroot/rootfs > > Imagine this being copied over to a totally different Linux-distro or > into a docker container. > > The "sudos" should not be in the script. So people can choose to not > use sudo at all or call the script with sudo. > > Maybe adding a Dockerfile would be a good idea to understand more such > implications. I wonder if there are build scenarios where we would also get away without chroot and bind-mounting and just using --sysroot on the toolchain. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux