From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6690944878080163840 X-Received: by 2002:a2e:914d:: with SMTP id q13mr24537250ljg.140.1558532260745; Wed, 22 May 2019 06:37:40 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ac2:418e:: with SMTP id z14ls226985lfh.16.gmail; Wed, 22 May 2019 06:37:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqz1M+3INuiwHjKAIBBVwnAzCJdD9Qo+A8cZQFOWqO/na8tESIPiVzF0B4DIqEKjJX37dhIZ X-Received: by 2002:a19:e057:: with SMTP id g23mr11999757lfj.19.1558532260062; Wed, 22 May 2019 06:37:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558532260; cv=none; d=google.com; s=arc-20160816; b=LgCIMVssoB9/ZO6wYMgMLIDYXUOhmeKyXxfbbTYw9vIq7+GQ3fqnvO3CaRTnq6jmdE 0sgybkHADpg12xNR8w8KKhQUuMMMNpueYjVvbDNTOJvVtDD02jm9HsTiYrpUD48eKLem sP4dYCOek9ieY0d4Qx6a1m1rITJ0RajjGzH1PmmpvrtNN4n9mpuhHfMBERlJz2iECQUy mZZSK/EzI0NhyGwbXyEybBX9/qRuJXC5ZEcvUMqMO8g/q2OBYqUa/yl9QNUtcnhhj4l3 Gnp2s/2+KtOuf/icCNJQ1OMkoICIgAnbWt94QBjlPKsmhlxjUAfUygbpNtWBtex9bxOf W01g== 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=kZQDm32S8SRQS3jH5RsGU27hBAscOk2FpZN+6KcPVfc=; b=0pXE4qq1/tEn5284XNAbX1oXjYApoH6HFIsHh/8Mf4A2yUkDAznxtY4/z2oy9MqdBx Z7JkSRo+OeydWKb27ic59774tniHr82182TbY1IJ7+HPaX6WTVvtuSzUNKxnu9AKAjQc iJiNhCC/ADO57v+89jLNUXliJDsMyy4cMcfCXuL8PZOgQmm4BpLAGL3KoeHaFfmj+59q MJI1wTMwpALDtixL27dY28yJSMA2KSnSKpXSwYPvuuicD/LsNpGqKpF+jYl7ac2fenNZ Y9+5GOtLGm5Bb/AQ+EpTJ6jshsrHmTAaqx21ZNF9GkSyBWOHo+uVul1d4lVgEh/0boDe 7A2g== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id a20si1963564ljb.3.2019.05.22.06.37.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 May 2019 06:37:40 -0700 (PDT) Received-SPF: pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id x4MDbdBb024801 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 May 2019 15:37:39 +0200 Received: from [139.25.69.232] (linux-ses-ext02.ppmd.siemens.net [139.25.69.232]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x4MDbcjZ027559; Wed, 22 May 2019 15:37:38 +0200 Subject: Re: [PATCH v6 1/9] isar-bootstrap-host: disable DISTRO_BOOTSTRAP_KEYS usage To: Jan Kiszka , "Maxim Yu. Osipov" , isar-users@googlegroups.com Cc: Claudius Heine References: <20190515101149.22187-1-claudius.heine.ext@siemens.com> <20190515101149.22187-2-claudius.heine.ext@siemens.com> <3745f4ba-e3c9-4d59-22e4-9746c6497f6b@siemens.com> <80d56fc5-00fa-5508-7fb1-976b4b5c61db@siemens.com> <514b7749-f950-ec44-b5a2-affcbfb91e6d@siemens.com> <0a86b0e8-8b57-d2c7-998c-d099952af86b@siemens.com> From: Claudius Heine Message-ID: Date: Wed, 22 May 2019 15:37:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <0a86b0e8-8b57-d2c7-998c-d099952af86b@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: HaXbrAYYZP5z On 22/05/2019 14.50, Jan Kiszka wrote: > On 22.05.19 14:15, [ext] Jan Kiszka wrote: >> On 22.05.19 13:39, Claudius Heine wrote: >>> On 22/05/2019 13.35, Jan Kiszka wrote: >>>> On 22.05.19 09:31, Claudius Heine wrote: >>>>> Hi Jan, >>>>> >>>>> On 22/05/2019 09.02, Jan Kiszka wrote: >>>>>> On 22.05.19 08:55, Maxim Yu. Osipov wrote: >>>>>>> On 5/22/19 8:37 AM, Claudius Heine wrote: >>>>>>>> Hi Jan, >>>>>>>> >>>>>>>> On 21/05/2019 18.56, Jan Kiszka wrote: >>>>>>>>> On 15.05.19 12:11, [ext] claudius.heine.ext@siemens.com wrote: >>>>>>>>>> From: Claudius Heine >>>>>>>>>> >>>>>>>>>> isar-bootstrap-host only supports bootstrapping Debian root file >>>>>>>>>> systems. Therefore deactivate any DISTRO_BOOTSTRAP_KEYS from >>>>>>>>>> other >>>>>>>>>> distributions. >>>>>>>>> >>>>>>>>> Actually not totally true, as I just realized: What about >>>>>>>>> bootstrapping the buildchroot from a custom debian repo that >>>>>>>>> was differently signed (e.g. because it is a condensed version >>>>>>>>> of upstream)? Seems we do need HOST_DISTRO_BOOTSTRAP_KEYS, right? >>>>>>>> >>>>>>>> You are right, I haven't considered that case. Well, the next >>>>>>>> task on the todo list should probably be to refactor and >>>>>>>> streamline the isar-bootstrap, and especially the host bootstrap >>>>>>>> process and fix those kind of issues while doing that. >>>>>>>> >>>>>>>> There are a lot of possible customization options gained if the >>>>>>>> current giant bootstrap function would be split up, similar to >>>>>>>> how the rootfs system works in the pre-processing patchset. >>>>>>>> >>>>>>>> Maybe it makes sense to also start renaming "host" and "target" >>>>>>>> to be compatible with the gcc nomenclature [1] in that patchset. >>>>>>>> I am a bit reluctant to do so, because of the breakage involved. >>>>>>>> But the further we wait, to more stuff will break downstream. >>>>>>>> >>>>>>>> The plan would be to rename all occurrences of "host" to "build" >>>>>>>> and "target" to "host". That would lead to the following recipe >>>>>>>> changes: >>>>>>> >>>>>>> >>>>>>>> "buildchroot-host" -> "buildchroot-build" >>>>>>>> "buildchroot-target" -> "buildchroot-host" >>>>>>>> "isar-bootstrap-host" -> "isar-bootstrap-build" >>>>>>>> "isar-bootstrap-target" -> "isar-bootstrap-host" >>>>>>> >>>>>>> >>>>>>>> I am on the fence of that change. Correctness vs. no-breakage >>>>>>>> >>>>>>>> Any comments about that? >>>>>>> >>>>>>> I would prefer to avoid such a renaming taking into account >>>>>>> needed efforts and possible confusion for current Isar users. >>>>>>> >>>>>> >>>>>> Is that build/host scheme then also in line with Debian naming? >>>>>> Then there will be eventually no way around it anyway. But we >>>>>> really need to do this thoroughly, specifically /wrt to >>>>>> user-visible interfaces, so that it will be one cut only. >>>>> >>>>>  From dpkg-buildpackage(1): >>>>> >>>>> [...] >>>>>         -a, --host-arch architecture >>>>>                Specify  the  Debian  architecture  we  build  for >>>>> (long option since dpkg >>>>>                1.17.17).  The architecture of the  machine  we >>>>> build on  is determined >>>>>                automatically, and is also the default for the host >>>>> machine. >>>>> [...] >>>>>         --target-arch architecture >>>>>                Specify  the  Debian architecture the binaries built >>>>> will build for (since >>>>>                dpkg 1.17.17).  The default value is the host machine. >>>>> [...] >>>>> >>>> >>>> Then the current naming scheme is already accurate for Debian. >>> >>> No? That is not how I read that documentation. "Host" is what we >>> build for and 'Target' is what the binaries we build generate code >>> for (which makes only sense for compilers) >> >> https://wiki.debian.org/BuildingCrossCompilers >> >> "Nomenclature >> >> TARGET is the architecture the compiler builds code for. HOST [...] is >> the architecture the compiler runs on." >> >> Mapping that on our buildchroots: buildchroot-host is where the >> compiler runs natively, buildchroot-target is where it runs on the >> target architecture. Thus, no need to flip anything. >> > > Citing from the wrong wiki, I got confused about this unfortunate > nomenclature (because of the fuzzy term "host"): > > "host means the architecture of produced executable objects, i.e. the > architecture of the host system where these guest objects will run on > (called target or sometimes build elsewhere) " > https://wiki.debian.org/CrossCompiling > > Given this, we should definitely avoid reusing "host" when doing any > renaming. It will only make things worse, specifically if some > user-facing variable that we used to call HOST_SOMETHING now gets > different semantic without changing its name. One option would be only > renaming host->build and dropping "target" from the rest. With my patchsets we could probably even drop 'build', 'host' and 'target' from the recipes all together and just go for the build host tupel. For instance: "buildchroot-host-amd64-arm" -> "buildchroot-amd64-arm" "buildchroot-target-arm" -> "buildchroot-arm" "isar-bootstrap-host-amd64-arm" -> "isar-bootstrap-amd64-arm" "isar-bootstrap-target-arm" -> "isar-bootstrap-arm" That would only affect the PN variable in those recipes, the file names would probably be 'isar-bootstrap-build.bb'/'isar-bootstrap-native' (which is what yocto is using to avoid 'build') and 'isar-bootstrap-host.bb'/'isar-bootstrap.bb'. For the variables just renaming 'HOST_*' stuff to 'BUILD_*' stuff would be ok, but maybe a bit confusing, because 'build' might be a bit vague there. How about 'NATIVE_*'? regards, Claudius -- 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