From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6656667439718203392 X-Received: by 2002:a1c:200e:: with SMTP id g14mr645061wmg.13.1549884818553; Mon, 11 Feb 2019 03:33:38 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:94a6:: with SMTP id 35ls2454432wrr.15.gmail; Mon, 11 Feb 2019 03:33:38 -0800 (PST) X-Google-Smtp-Source: AHgI3IaZG9z5RYyEf7kcW8uG/+ddfmrDzp8/7W7n3lzhRLBFC2AbxnFXrtA7+3LYziu5vDEPhW1X X-Received: by 2002:a5d:564d:: with SMTP id j13mr621305wrw.27.1549884818126; Mon, 11 Feb 2019 03:33:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549884818; cv=none; d=google.com; s=arc-20160816; b=jVk7Goh8eWhN1M+/8Fk6BM4ybuDc3CfF2LwwQWhkYG6gsVhsbxm2hihY4yhbJlm9s/ 4QrO1grCh9wx6EEuMhSkdTIWRoiMaPdd7/eHxqfwYIpoGsHNYiJzg5+67wNUcOpxq+rW AGg6CfPzT7mULDJqk4Gmn8t6o8cjM5CFIBOZkZ6HljqTrJWIor4atI2R1mJ/6PgIvHAb 5BdBgkoo9za5VN+MfhWfBs28ISnoMrkm4Rklq8NERJjQxESG309QRr1R3QLU0e+vD+nl l6UHOIi7a9pFm9UtSMoJt5OX2C3BepNbh8uJ8wdMUekWXmPXeZIhoTCvMgDlwdha3ofF Z55Q== 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:to:subject; bh=uZ01vXAixBqpxB5XWsfGFOKMjCIXuelY/g372e8ZOTM=; b=nktAW7Kz301sOuv02DLrkaC6szDlaXUVwApIa9oXjHgw+bv3dmMgGyd5FfVplgdfye pwgMyx9P2fiNLoBK+J7WuZDR91IqwciSjX7ha1q6+gKx9YopVV+Z8HNzRvR6NlapOF+z MXe9mjwVNjJ5pq8KrwGH69suu6xCEbZW+k/D8E1XnoceoM7HlluBYSGC3cK9Dq+OVGv2 Muh7v+osHc7zo4PgibtYren/MTPUwDn6+fAtcR0i7IbcunJscwR2onguGydDHyg9FTv6 0O9aIBBR3700ViEkmZkhmonZIOVeuCVtAa+ujwo8ASedUO3lAh+hsEXccAbt2hkOfmpm bs/w== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id t11si86475wrv.4.2019.02.11.03.33.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Feb 2019 03:33:38 -0800 (PST) Received-SPF: pass (google.com: domain of claudius.heine.ext@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 claudius.heine.ext@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id x1BBXaGj006392 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Feb 2019 12:33:37 +0100 Received: from [139.25.69.181] (linux-ses-ext02.ppmd.siemens.net [139.25.69.181]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x1BBXavA030919; Mon, 11 Feb 2019 12:33:36 +0100 Subject: Re: [PATCH v5 1/5] meta/image.bbclass: add image_do_mounts for image specific mounts To: chombourger@gmail.com, isar-users References: <20190211090921.9294-1-claudius.heine.ext@siemens.com> <20190211090921.9294-2-claudius.heine.ext@siemens.com> From: Claudius Heine Message-ID: Date: Mon, 11 Feb 2019 12:33:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: YH8zc7M7Fdfi Hi Cedric, On 11/02/2019 11.49, chombourger@gmail.com wrote: > Hi Claudius, > > So the idea is that platform developers wanting to add their own mounts > would use a bbappend to do something like? No that is not something I envisioned here and currently I also cannot think of an additional mount that should be available for an image recipe. Do you have something in mind? > image_do_mounts_append() { > sudo mount > } > > is this something we would want to add to the documentation? That pattern follows the 'dpkg_do_mounts' patterns from the dpkg-base class. There is no documentation about extending mounts for that. That is not really an argument, but since dpkg_do_mounts is not officially build to be extended that way, I don't want to officially support it here either. If extending available mounts more easily is a feature we need and have a use-case for, then I could think of ways to make build a better interface for this. As the patch stands now though, this is not an interface to be extended by other layers. Thanks for the idea though :) Claudius > > Cedric > > On Monday, February 11, 2019 at 10:09:24 AM UTC+1, claudius....@siemens.com > wrote: >> >> From: Claudius Heine > >> >> Signed-off-by: Claudius Heine > >> --- >> meta/classes/image.bbclass | 21 +++++++++++++++++++++ >> 1 file changed, 21 insertions(+) >> >> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass >> index d8fbfd5..bec62cd 100644 >> --- a/meta/classes/image.bbclass >> +++ b/meta/classes/image.bbclass >> @@ -14,6 +14,27 @@ IMAGE_FULLNAME = "${PN}-${DISTRO}-${MACHINE}" >> KERNEL_IMAGE ?= "${@get_image_name(d, 'vmlinuz')[1]}" >> INITRD_IMAGE ?= "${@get_image_name(d, 'initrd.img')[1]}" >> >> +# Useful variables for imager implementations: >> +PP = "/home/builder/${PN}" >> +PP_DEPLOY = "${PP}/deploy" >> +PP_ROOTFS = "${PP}/rootfs" >> +PP_WORK = "${PP}/work" >> + >> +BUILDROOT = "${BUILDCHROOT_DIR}${PP}" >> +BUILDROOT_DEPLOY = "${BUILDCHROOT_DIR}${PP_DEPLOY}" >> +BUILDROOT_ROOTFS = "${BUILDCHROOT_DIR}${PP_ROOTFS}" >> +BUILDROOT_WORK = "${BUILDCHROOT_DIR}${PP_WORK}" >> + >> +image_do_mounts() { >> + sudo flock ${MOUNT_LOCKFILE} -c ' \ >> + mkdir -p "${BUILDROOT_DEPLOY}" "${BUILDROOT_ROOTFS}" >> "${BUILDROOT_WORK}" >> + mount --bind "${DEPLOY_DIR_IMAGE}" "${BUILDROOT_DEPLOY}" >> + mount --bind "${IMAGE_ROOTFS}" "${BUILDROOT_ROOTFS}" >> + mount --bind "${WORKDIR}" "${BUILDROOT_WORK}" >> + ' >> + buildchroot_do_mounts >> +} >> + >> inherit ${IMAGE_TYPE} >> >> # Extra space for rootfs in MB >> -- >> 2.20.1 >> >> > -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de