From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6566568349648551936 X-Received: by 2002:a1c:8ad0:: with SMTP id m199-v6mr127990wmd.5.1528968901332; Thu, 14 Jun 2018 02:35:01 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:11cc:: with SMTP id 195-v6ls1597339wmr.9.canary-gmail; Thu, 14 Jun 2018 02:35:00 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIuSY8x0F9T6h6QmUz7BxTptdd32Gv55wbXR67x6fzjbxrJVat+ZT/kuJGISbABRsCi+xTi X-Received: by 2002:a1c:640b:: with SMTP id y11-v6mr126186wmb.13.1528968900944; Thu, 14 Jun 2018 02:35:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528968900; cv=none; d=google.com; s=arc-20160816; b=qIreVg8iCS9uwJmW1KFOP9IScYdwj+qrUha6zunxw3lOCn4eEVcqUpUfh/QoMMXtow uk/vupKjzKB14B5IJA8DiPi6slpOn7jY4u3B4e9rh5L/nOYfu45kkXqU7hDfZybAvzvY or7ytE0/h864jrKkxMGkO1Zh1C/KE2VxCydbDaOa9i6SoRjegavY4qW0eKXNfqzjseXq FdkM25s83feHrIWvjVDY80DO6gF70Mvpsb2NV09Wi5nFgXeaaMRvggP12zyC6Xb99w+B Y7CdNuTRlc4f51RJszjsoTe+TQDUPx1Bw++jtHruv4gGEvBoFurNk56I5G4ejIN/8Rve 0M2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=67FRzPnT0qdeKmmSO3gLO07SBIjBS0qTRv+5BsWf+3k=; b=l+JW07fERrtUery7bUwnrx/9j4rE+g9FXrgc6NwgvQl/t6MfU+ipKFmE+VULQqYCBH YLOKz2arJv7yvKtElp/a0g5dsk8DrdF048WbjRhJplnVoC0uRskCee05/oiQQXt0iVvJ DEuAGLRnjHHsVGX3u/1Cq0yOWdhkXAifUhdyQ5bis0a435k9pQkxl9WYaiL/LNh80P2y 1Kd9c0Aexhuwt2lxBQZ6f2gBoayf5amOhjWszEaYzO0o0e1z0IGBQ2EfQM71mDLqlHMS jsb0bF6af5vaw17EyDqGgUw2J3GsdMYMff+DzSnfv165bfDDt9Bisk6rY4u/5KV21gnR Z8og== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id r7-v6si67197wmc.0.2018.06.14.02.35.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jun 2018 02:35:00 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id w5E9Z0br026302 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Jun 2018 11:35:00 +0200 Received: from md1pvb1c.ad001.siemens.net (md1pvb1c.ad001.siemens.net [139.25.68.40] (may be forged)) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id w5E9Z0m8026389; Thu, 14 Jun 2018 11:35:00 +0200 Date: Thu, 14 Jun 2018 11:34:59 +0200 From: Henning Schild To: Jan Kiszka Cc: "Maxim Yu. Osipov" , Subject: Re: [RFC PATCH 0/6] ISAR SDK root filesystem Message-ID: <20180614113459.07df1ee8@md1pvb1c.ad001.siemens.net> In-Reply-To: <52c0c6db-ca7e-87a3-c471-d247f4118584@siemens.com> References: <20180613135829.3151-1-mosipov@ilbers.de> <20180614104826.0d954ed7@md1pvb1c.ad001.siemens.net> <52c0c6db-ca7e-87a3-c471-d247f4118584@siemens.com> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: DysSW2H0ubFY Am Thu, 14 Jun 2018 10:51:39 +0200 schrieb Jan Kiszka : > 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. I bet there are. But this approach is very generic and gives you a more controlled environment. People could still use "--sysroot" with it. One limitiation i see is that it is not clear how you get your code in. You have eclipse open on your host, you probably want to mount your eclipse-workdir into the thing. Not to mention the build-button ... hammer-time. Maybe we stick with the "debian around the sysroot" and add a "--sysroot" from outside example? Henning > Jan >