Re: [RFC PATCH 0/6] ISAR SDK root filesystem

[Henning Schild <henning.schild@siemens.com>]

Am Thu, 14 Jun 2018 10:51:39 +0200
schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> On 2018-06-14 10:48, [ext] Henning Schild wrote:
> > Am Wed, 13 Jun 2018 15:58:23 +0200
> > schrieb "Maxim Yu. Osipov" <mosipov@ilbers.de>:
> >   
> >> 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
> >> <package_name>:<DISTRO_ARCH>` 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
>