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

[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.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux