From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6617812835611181056 X-Received: by 2002:a1c:93d1:: with SMTP id v200-v6mr48713wmd.15.1541665733353; Thu, 08 Nov 2018 00:28:53 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:d3:: with SMTP id 202-v6ls48334wma.15.gmail; Thu, 08 Nov 2018 00:28:52 -0800 (PST) X-Google-Smtp-Source: AJdET5c/90N28EBUR6LiDRE7udG63Qwm4O+P/gxm11IQI5uOD7BUUc23gp9DgV1opMvNes7rNYtw X-Received: by 2002:a1c:da90:: with SMTP id r138-v6mr87984wmg.1.1541665732809; Thu, 08 Nov 2018 00:28:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541665732; cv=none; d=google.com; s=arc-20160816; b=T9xhCHM89g7O+TRMnlGchumvsMA64IPwcJhOTYCa2KzXSKeUtW2WiB2XSOyJg0xe8D dS2woEO9DMJkHhxdu2zQ4GcVNthNJgZqtmV7G9iBOmLFc4pn+D9mgl1dHSv9zyacjYNF 4Wnq91/+ltjynfEiBiEKF/GSRrAK9uHIoD9Ypw8la8pg7XJ1lFyAUrxtPWq0a0jbY/dm YObv5f4VUPrOF/Y6DH9D3fzq4uHZu5JW6Sou9BIgDQwLvjds9DtyaH9G79OwyYIvllqD mOZ4gjkFtoENp+ri20ME7gK/t9VbqlELjgOtxOFUjFAtKa8IiGgLQlVSV3ItE30aXMGo l0zA== 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; bh=q49VCvRf5bn91dnI05JuJrq1yy0ywxuHUi70WPkt7eI=; b=hJrx0pExU0E6hhnraadArCMJC7wfaqd2XNbHuplh+Cl234wz9U6h2/onbIzbti2KEU 9CCZ/kY4WyEdhfXgv2h2IKsniHIBqfrEW6Ceh4iQJkCLBWjP5C0+fegwW9fXAr6lpxda CUJvyXsaKUdmj3Zs6DeDHWD0AboQBq6xVwvVQsQkq/UeuFRYzlV7W2rr4FkTLH7WUJM/ 1cMTpPDu/Sl86rtTion2Izvy9ThKUOktYtvsXypuU/B2tVJGuPHndchY6S1TKrVXsX6c 0n3pnP3wPzG+5KYoZGXOri/HdM3B5LzTOrIZhBti3pil66mDMTg35MJ8+iNN7EuBaMw7 afHg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id n6-v6si129032wrj.4.2018.11.08.00.28.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Nov 2018 00:28:52 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@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 jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id wA88Sq63024245 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 8 Nov 2018 09:28:52 +0100 Received: from [167.87.13.219] ([167.87.13.219]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id wA88Spar031554; Thu, 8 Nov 2018 09:28:51 +0100 Subject: Re: [PATCH v3 2/2] isar-image: refactor do_rootfs() To: "Hombourger, Cedric" Cc: Maksim Osipov , "isar-users@googlegroups.com" References: <57847f7a-9b85-65ef-b11e-8952bf532e0f@siemens.com> <20181101101302.8674-1-Cedric_Hombourger@mentor.com> <20181101101302.8674-2-Cedric_Hombourger@mentor.com> From: Jan Kiszka Message-ID: <8cf7ef04-b74b-caea-53f0-55971dedecac@siemens.com> Date: Thu, 8 Nov 2018 09:28:51 +0100 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: s5jvncv+shoT On 08.11.18 08:59, Hombourger, Cedric wrote: > Hi Jan, > >> Why making this a python function? > > To align with Yocto and ease extension of do_rootfs should we need to (we probably want to have some guidelines for public APIs and one of them should be: make them Python functions because it allows children classes to use the full Python paradigm instead of the somewhat limited shell environment) That is not the actual reason why Yocto did this. The reason, which would have helped me to understand the design, is that it allows downstream to define the language of the subfunctions freely. bb.build.exec_func will take care of calling the function as shell or as python, whatever the user chose. But, as the subfunctions are shell code, appending/prepending still requires shell. If you do that for the rootfs function, that must now be python, even if shell would be more appropriate. Here, it is impossible with bitbake to provide freedom. If you want flexibility, you better model this with tasks. That is something to consider seriously if there is a hooking use case. > >> What is the reasoning for the chosen split-up? > > If you are referring to the split of do_rootfs() into smaller functions, the primary objective was the reduction of the function complexity. Another candidate for such refactoring is IMO setup_root_file_system(): it's a function doing dozens of little things. It also allows classes inheriting from isar-image to hook themselves at specific points in the do_rootfs flow instead of being limited to pre-processing and post-processing extension points (do_rootfs_prepend / do_rootfs_append). I'm not against breaking this task up, but the question is where, and also how. And that should be driven by foreseeable use cases. Eg., isar_image_conf_rootfs seems pointless at this stage because there is already DISTRO_CONFIG_SCRIPT to do customizations. If we want that thing to be extensible (rather than just replaceable), we need something else. isar_image_gen_fstab is possibly something we do not want users to play with because that could easily conflict with what wic does. > >> These are all recipe APIs, so we must be more careful with such declarations. > > You are right. If isar-image-base was viewed as an API, we probably want to highlight the change in the ChangeLog. I can do that. Once it is clear why and how a user should overload / append to those APIs. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux