From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shymkent.ilbers.de ([unix socket]) by shymkent (Cyrus 2.5.10-Debian-2.5.10-3+deb9u2) with LMTPA; Tue, 15 Oct 2024 18:11:42 +0200 X-Sieve: CMU Sieve 2.4 Received: from mail-pl1-f192.google.com (mail-pl1-f192.google.com [209.85.214.192]) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPS id 49FGBdVd031586 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 15 Oct 2024 18:11:40 +0200 Received: by mail-pl1-f192.google.com with SMTP id d9443c01a7336-207510f3242sf71820915ad.0 for ; Tue, 15 Oct 2024 09:11:40 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1729008694; cv=pass; d=google.com; s=arc-20240605; b=OT0wJhhIVnaTypkt+fodEx2+9l10iW+g6bHQG27od2ULPBnzH1w1BlcvTtqN4Vo1ub 1LR5K31I8lU3a73LU1OQtrS7LYxzvP0/6ZJSVsaQ8ASBKGwowmeIPFyZhMVf/nh3QbVt F0WyNxxPlWMbKStQnTahAEigC1j566TGEKv6oEk6Uuj58pEpsQ/woXmFdM7dbmxcEJBD 6jMO2DyXVb4Z2AtIId2+n8gTFAO6PaXqbENSrAkN9DHcwV3F6kH5Kg+R1WuERd3ryU/r YjHAcpv+/fwqdk0uhoq+jdvyVe9TwBMQbnuN+V5cH8mzMiXGvEZgibV/4R8SGb67XuRm zQ6g== ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version :content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:date:message-id:dkim-signature; bh=JZRT9NuetmZWg8U1KwzoUhLxlFC+Dy+N7xaw6bRAq/U=; fh=75RODE3AnFuzZsF3+PR7PxUEAibfvc2xu5RZuJIx2ag=; b=QBv7tp18d278oA3IZMXL6oVMN3XDn5b4hooOf1kUigBWGzHFBJ1gP9lSABGpS3+TFi EIIHC7pjL22fQrfnLxszwmT46TJCNWYcUe/484rvc/W1O04zPcTEClVahNXxq6sWSqeC aoRkdSq9UNwf7zxtM8lYFiEzorUs3TQNIUp361Uz+0SB18EVXDaouurzUIwGI3Ryiz9k bO0LehUoOZSPVWfYa3QfIwNpJTcb0EdBZ1eFFYtzBabXc44iwWXV062IB4lW/r7RMmPk 6AElgC2FE9ehbvoDeCmTvrdVhkKOfX7catkAVtT16E9wLfdGNau0mvCBMwuavg0wwMnH RBuw==; darn=ilbers.de ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@siemens.com header.s=selector2 header.b=KZgICYSZ; arc=pass (i=1 spf=pass spfdomain=siemens.com dkim=pass dkdomain=siemens.com dmarc=pass fromdomain=siemens.com); spf=pass (google.com: domain of chris.larson@siemens.com designates 2a01:111:f403:c101:: as permitted sender) smtp.mailfrom=chris.larson@siemens.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=siemens.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1729008694; x=1729613494; darn=ilbers.de; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:date:message-id:from:to:cc:subject :date:message-id:reply-to; bh=JZRT9NuetmZWg8U1KwzoUhLxlFC+Dy+N7xaw6bRAq/U=; b=l4Av5qLn+htNcATKfQUtiqNTwlKjNuKV7bit59cGBm7iD+9Mj4g1St9eOZ4gewJQgG BqL4/qKTBA+o39T/5yIfZRreowVQzdqXAy7kiHWpWuXrgcWUNFkGhsU2+DZOVMDF4A6F Px6Cfm55ukSxEibiwuPKhZb8YxJYjiJn1+vhXg+sBw+nl8I7ZNQGxFN2Rl9U5HKJT+dM 0WauO7p8Iiz3osXGA6vHq6RIYK2dN3CmVe/1TXgismSPw7SIJSId2zEuXHrLYmYpasr+ OJCBTaED1b9LghtTgL1bUSS4Jv4LifagAiEFMCO1jq/YaADk5QqmoyFIvL1SXebVdvXO Rniw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729008694; x=1729613494; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :x-spam-checked-in-group:list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:date:message-id:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JZRT9NuetmZWg8U1KwzoUhLxlFC+Dy+N7xaw6bRAq/U=; b=KLzZrKELjIfu3AhIHMYOu+6aEbfX+XLSSME1df3HJ/uPbwpAqQttb69quaFNJY10RS 4YgoHp2y0IKB+GkQyChKYjA3XA0OEQ6vvaCKLyKV1qheBmCzduUq0W2nIUMcDkoCEzIi 7ZVY0426TVy+u2sEAc5iaUZ3Pvvroky11bByMa/iVubU9B/RWRmNQLvEgM2r1OCZGOIe B6gHw+228eHrW1Q3qPkUguuyonYbZ0W7hvxmjmPYBDgu8RN5vJJEa5gSGtaFYR0XDR+4 pHVuRlG9r/pJfsQrsZdxtagCS7sG5UUg6+Z8mllwtERA9T68ZJvyue6Vxd5PaoCmoyJT o6cw== X-Forwarded-Encrypted: i=3; AJvYcCXBS5DT7Wo8IFDe5WFFZB6x9LtE9rv3hiFDbmIZzfY0HaPRICOp3txOfnsUxLYo3elg2z+4@ilbers.de X-Gm-Message-State: AOJu0YzGUlmwbWK5ox4blVhRhpkHNtyo56tvPE8MaHtFto1dSWE+xgtq Sl/CM+ftJUTzuJlCrSNjJiOq9aT2K2teSiAfDxQhgHW56n26X34O X-Google-Smtp-Source: AGHT+IFAB0pLpPG8+wjxRCx2HNiuxKBXaY8EmatvV+yZ5mlUP+BprhT7p0VkVeCtEaI/YQUY/s9IwA== X-Received: by 2002:a17:902:e548:b0:20c:968e:4dcd with SMTP id d9443c01a7336-20cbb1a9879mr224479155ad.7.1729008693391; Tue, 15 Oct 2024 09:11:33 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:902:f54f:b0:1eb:1517:836a with SMTP id d9443c01a7336-20c8069569fls19043455ad.0.-pod-prod-06-us; Tue, 15 Oct 2024 09:11:32 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWafQWfmZqT8vACX3UuLre1LLRCPCJxjkg/TDVxTeHGfV0/pKJBMFJW2XhQVtUNW8+74WMxFlCQ0sSm@googlegroups.com X-Received: by 2002:a05:6a21:78e:b0:1d2:e889:1513 with SMTP id adf61e73a8af0-1d8c959533emr18866346637.17.1729008691915; Tue, 15 Oct 2024 09:11:31 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1729008691; cv=pass; d=google.com; s=arc-20240605; b=Bva9wBfLTkN6Lgl+5NmSD7Ho3jqwQ8bR9NQjzlDc6INOfQst48NAnydq95AuOjaUK0 yxf8FIauwUdrVQbwzz72P1M3IRvg+kjgM0Dj63+QXS1wdmGhZGqzq4NbvLWYKf6qeFtP Qv3Xj7ztqLD+4ackazGS1xKd67D8R+tESlwzU1PHN4LKg79CX68ZicfpWFnJ01EwuRo3 /xkXZEN72wPXrj9aOTjbonQ3aQEZ6mWE2L6QxpAx+5xBHu00P+gBUUuJfvinYzTlDnjO nF7VpHDXy79WEEBAJn+AKGtaiJcNFS6zUJTlYwgGNjAeqlTTdkSmSRiN/Rkntr6IonYg RvrQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:content-transfer-encoding:in-reply-to:content-language :references:cc:to:subject:from:user-agent:date:message-id :dkim-signature; bh=RPiWg6qObWEfY6O8dKG6POkm7iMWrvvFMrYhJAuapyk=; fh=GALCAbdvsRUAhGaL+/yETx72z2kfWkPXFi3737KbwI0=; b=fdAY+8zkYXxtHy/AVISBEfUeqXIt7AexMnKlnkUWhYvGM88VytzVSx7gB0P3tX/FCq /4syRe36CfXDNyZpWFVE1T5Alx1Li0Nxvkni/r7yWUhrs6isxxoapy+35ksq3EToU+1+ n1RxmGMrsIEM+3SU00rsxU7cVgcSdLuRoBtu1BRkv5PVjoLP55eKXNZ3CzxHk3us+lnl 4zmcNI1oq2hsceUkYIERL/qTOoRO0ID1MD7dIujq2ook0CT+nQIeo6ycNzsRStzSyVEm y7BoUtUL/T9lbj0tzAhsAclXeP8q5E5YsBUiAKZ4pDUHEQLiTCGfAu2JJmriYJyoO10M ySxA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@siemens.com header.s=selector2 header.b=KZgICYSZ; arc=pass (i=1 spf=pass spfdomain=siemens.com dkim=pass dkdomain=siemens.com dmarc=pass fromdomain=siemens.com); spf=pass (google.com: domain of chris.larson@siemens.com designates 2a01:111:f403:c101:: as permitted sender) smtp.mailfrom=chris.larson@siemens.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=siemens.com Received: from BL2PR02CU003.outbound.protection.outlook.com (mail-eastusazlp170100000.outbound.protection.outlook.com. [2a01:111:f403:c101::]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-71e7760af98si74452b3a.4.2024.10.15.09.11.31 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Oct 2024 09:11:31 -0700 (PDT) Received-SPF: pass (google.com: domain of chris.larson@siemens.com designates 2a01:111:f403:c101:: as permitted sender) client-ip=2a01:111:f403:c101::; ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rL+gDwF+VVGDoWpapaEcLU95c+LycIEbUlFliYhvxMnxPwryF7b1Meovgy8kq+WfcFVStuCPmgZqgto0/CvdajbdTkWHZ6RnKRt37OtJTmEUZZdSJV6Vey1a9X553hbQ1WhHG8xxf2GwMOhemrqDEf039jzLRVHvRTyIdsjzPhUQojoiVdHhfnXySy2XzcuuMGt4CNwyOXyDgyXLy0lGR1sNmm/tfflmlq1OKfR+WWgAG3th00/BE4XqbTczbwLHMHqPdMW2p7p/NdWL+8eIy1wXCxd41HGdfaUKf4GJiZL6Z82uetaejjfQjAPrA7I33jKdRGklbY8OglNui2E2qQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RPiWg6qObWEfY6O8dKG6POkm7iMWrvvFMrYhJAuapyk=; b=idGGiKRngdkpNH7HcQwyDqXNbI+d6P+JPmx33gc8FHXuI1NJxUpkIMGZUixyXnkCFfGecq/hgC2Lr8IBU8IaMDKbsJw90YsKwZ4DCao2oroIeVP3FPE/6c3RCN2nOzyAJGK0U32AdT+QJ27uv5Grq/px+zvtedIuc/Ql+RRaHWtXog7lJpBsyZFLDPYA65J+Gt6K5N4mpbPbA2Rhe7Y/K4V0dWWRaXMe7T/26EzXrxcYMWr9y8WvEKRazebD0aNgSfouawUW10ouHmlzjalzPVDsFm/vnh2LBmNjQILBMfpaxTt0TGLEj8uMpJ6y7Z+MFsbPrM1urxR0Tkxd+vHQRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none Received: from BN0PR07MB8375.namprd07.prod.outlook.com (2603:10b6:408:12e::24) by CO1PR07MB9082.namprd07.prod.outlook.com (2603:10b6:303:155::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8048.27; Tue, 15 Oct 2024 16:11:27 +0000 Received: from BN0PR07MB8375.namprd07.prod.outlook.com ([fe80::a27c:dbcb:4b45:bc5d]) by BN0PR07MB8375.namprd07.prod.outlook.com ([fe80::a27c:dbcb:4b45:bc5d%5]) with mapi id 15.20.8069.016; Tue, 15 Oct 2024 16:11:27 +0000 Message-ID: <5ddf60dc-f297-4d5f-9de2-837fdd0e7e75@siemens.com> Date: Tue, 15 Oct 2024 09:11:25 -0700 User-Agent: Mozilla Thunderbird From: "'Christopher Larson' via isar-users" Subject: Re: Proposal for Adding OE/Yocto-Style Features Variables to Isar To: Jan Kiszka , isar-users@googlegroups.com Cc: "Hombourger, Cedric (DI CTO FDS CES LX)" References: <27f2f225-d7c4-40dd-a4db-431eeb31cc52@siemens.com> <086d0928-13c2-478d-8e39-c89c15526912@siemens.com> Content-Language: en-US In-Reply-To: <086d0928-13c2-478d-8e39-c89c15526912@siemens.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: BYAPR06CA0060.namprd06.prod.outlook.com (2603:10b6:a03:14b::37) To BN0PR07MB8375.namprd07.prod.outlook.com (2603:10b6:408:12e::24) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN0PR07MB8375:EE_|CO1PR07MB9082:EE_ X-MS-Office365-Filtering-Correlation-Id: 85eaba68-ff61-4e98-9b6c-08dced3405c7 X-MS-Exchange-AtpMessageProperties: SA X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|3613699012; X-Microsoft-Antispam-Message-Info: =?utf-8?B?eVFEZkpqNENsUHZzSkdrRFROZzRQSERKblpxN1FURjVSQkJGZThyaUJldDJC?= =?utf-8?B?dU5JYzE0TnFwUjVsSDdwSnMraXNGbHIydzdMNjJpZVY1WG9EbmxUYkJpaDV0?= =?utf-8?B?REpjdTArbzN0dkt6K3c0TXQvTUtqL1JsKzZQUVhNY0JTcEVoYWhINkpQSXJp?= =?utf-8?B?TWZQSUhkOGZNWHR3amlGQnBYVjV1aGpOQ3YwaDlXWFZmbVEwc29qVjI5aDRx?= =?utf-8?B?NzN3ektRamplbHlFN05pYTQ0TjQydTJJbU9BZUVDS3Z2Smp6cnRublV1QzIy?= =?utf-8?B?WmkrSjF1RG5HT01aK0pjQ1FjRzYwWVJYdit3dHA4djNDamoyS256N1kxYTRy?= =?utf-8?B?NDZZQ2hqY3ZIRzVIek5CRGsrMnp3c2NqQWUyZ3l3aDEyVU1kK1lySUNMaE5h?= =?utf-8?B?Z2taMzB2QmpqLzd1L1JheFlRT2RXNEtwQnd1Nkd2ejBVSkt6cnArMkVFci9R?= =?utf-8?B?dmJ0ZzNMV2FOSHRsNm45c3JGdjZtVk9xRElWV0ZNRTI4ZEZZZXNpRXhLbzBU?= =?utf-8?B?VHZTMXhLU0VidGg1dzIxc0NjYUlqajB6azBaenI0MTVLWjAvbjc5Z2NRdjhn?= =?utf-8?B?NnEybnprZytGTDI4TC9BVzJwQm1BczRhQlJDaHdTc3dXaEtIeE9SSGNtNkpG?= =?utf-8?B?K3lZOXBBL1R5R2ZzRFdXSUZ1djBLQTdEbnJESzVadzgrOHZMZDZOMU9lcjhU?= =?utf-8?B?NTJSMC9PM0hjWlEyUDRRYkFrWVM1Tnh6TVAvRGkyQ1RJZkdpdkdoZGMxQmFq?= =?utf-8?B?RUh4Z0tEbE1GK1poWUNtamtETjlkOGtUNTE1c3VMMjlsZmw2eE45K0dHNHhy?= =?utf-8?B?UUVyRmluVk1zUkR5VjRjeUlFcWdnMjBycGF5WU1Ga1dqN3dmamZoV0NPYjBt?= =?utf-8?B?djBHVWZKUHBSTCtWblVxSUpGUU5mQWdZNU9tZXBKZTlHWGFZdmpTdy9OSERK?= =?utf-8?B?K0EremJ1KzNqdW42ZHNYanRhUWN4Nzh1eHoxTjNnOW1Eb3NGeUtYREtPMUZk?= =?utf-8?B?c1ZFNWtWVDlQWmswbFFPVlo5TU1EblRmeXFDb3R6ZERkOFVsL1cveWRvbm1X?= =?utf-8?B?OUs1RmJybVlnTWwzRE1mZlh4aGRXUkVrUVFxMkNQbWV5TytYdnE5eVYzTmJK?= =?utf-8?B?L3R5ZWlvYzU4MHpnZ0MyOXFIRC9kMlZ1QWxYbm1oQVFMMXBOUXBIMnUzMmhp?= =?utf-8?B?Y1g5NkR2TXoyTzBaMHBZVjFjNGZqdW1ER0RCbmt4ZmZFNVNsbmlBSTc0OGZh?= =?utf-8?B?Qlk3dFpOZFlZWHFCcm5JWW9zN1hnVy9iYXBLZlNoZjBXVEE3QXEweFFnbDRM?= =?utf-8?B?cVY1QzUzNVY2RU1PYTdMQVN0TjZVbUtmVFljN2lVQktoaUxRQXZtT0RjbDI0?= =?utf-8?B?MG5Cam1ZekQ2TTA3cDN0VStCc0dnS1F1ampKaHl3QVdRSU1hUjFEdHlQWnBz?= =?utf-8?B?dDkzTDUvNFdKRVhWVGtaRStJenZORDZMVUxOa0ROV0FCRldTTE9MejdhR0hR?= =?utf-8?B?UVdFdmgrYlZhSXhQTjZ5Q1VIQTUyVHZwcy9UY3JZdUdoNmRhV05lUzIzVG5K?= =?utf-8?B?UHpRRjJXMmlodnFqZ3hXTkplVVd2aU9ia2IxdjdWcmZjdDgyOFNJMk9uaGZQ?= =?utf-8?B?czFGQ2FmU3FEQVBlZjdicVljdHRuLzhFY012Wm1GSXMvdTc4d3FDczJYQTNt?= =?utf-8?B?UlA4RG5IQURZeGdqUGFJR2hiaVp0YWJoUUJZYnRzK2pZMTd6bWlYbjhRPT0=?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN0PR07MB8375.namprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(3613699012);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S2kzSEQwVVhOSGRXREYyS3krRkEwVG51K1dVSi9jdjhMcVZRZXo4elhqdktr?= =?utf-8?B?K2FFbGJQUm9QUlo5SmhpVW5oenRCRTNpUlNqR2xqVkJOZE1uVDVDWDJBTXFU?= =?utf-8?B?K2tJbWFUZnNHTTRNV1YyclNQelpsNVozcU4rSmlIdGdraHlmZ1R2M3BLRWVv?= =?utf-8?B?cmIyRlB6Ui9uQXhOREhZWE5JSHNWVFh0blhUWWJiZHhFODY0bDl1c1RSMFBE?= =?utf-8?B?U2R6VnhQdDJCbVZvVXVNaGVwTFMwcHNpUHFYdWJ2RU1BbFRWUU1wQkRIMUgr?= =?utf-8?B?dmYrQnFwbll0ZlBKa2Z1SUNVVHZDdGZJYzdqTXZRV0NKdHgxdHo2ZVJINWZV?= =?utf-8?B?eDdraWtRbWlaaGtsYm9yTEIxSFZzNmFsNXNzTDhBNUYwU2RKTmpQMW9XdEhO?= =?utf-8?B?VnRVMzdqbTRVSFAza2Q2WVhrTzk4alRxY0lONnBad25wU3BrdytsVE5iR1o0?= =?utf-8?B?TzJOMlZ5TlVGMmpQUHpKTWZ6UVJGclU1Q2syZUxlK0VYWHd4bkg4bDk3eUFB?= =?utf-8?B?Y2k2SHZJWEJMV3VFcmV3Q0hwRWFIWHdFUm5sa05WZUdma0V4ZGNSaFlqVzRO?= =?utf-8?B?Z0R3STZQVm1DUUFLajJwVHpXeDRISlF3dDhWM21sdXF2MnhqN1ZOMmlMRXdn?= =?utf-8?B?b005WHFoWGxUSEp3S205akptVjVRdHVyWlZJcWgxQ3JhRlhRVm5iUmZVVlNM?= =?utf-8?B?U1ZsK3A4ZE1mU1MxY1czS3BjTWJPVXBkRzZRak91dWV1Nm9Vb3FDalZud1lk?= =?utf-8?B?T0EyOHlUN0s1aU9DRXk5VFlFVExzSFgvZjVLNEVXWHlBOVd6UStmNkZRbjFu?= =?utf-8?B?NUJldkRjaGNPV1NjWlBJbzNWbFpZam9LNmFVZjJRWHZyWmNxK1hvWFVMWnlG?= =?utf-8?B?OVU3dGx0UCtKNCs3aG41QUlHWDFqellyRDE0UjY4T0Fyc2liYVRtdmdSWGlD?= =?utf-8?B?enhzY2twZ2x6RDZJZDZkdW80R1ZmclhkaWpmYTh2TE15blFrVmhoRG9ydkZN?= =?utf-8?B?TmxjOThRRU5QU1dyOS8zbnZ0UFdWakdPOHJyNzRkb0QyTEdxWTJUZnN3cTR3?= =?utf-8?B?WFN0SHNwWmowSmYwQ3lacm1mUnRnbkttWmUzSlNLUW9KRnhLTjFwQmR2b0lp?= =?utf-8?B?SC84SHBxakUwNko4Z0txeGlTZzVzbDZnTkVyalMzSTkySUlSck5NbnluMTcx?= =?utf-8?B?R1BRcXlSbzFScFBUYkVsNXptdVc1VlRhMDhCN3BWMnByY3BIemUyZ3FxMzd5?= =?utf-8?B?d0NOZ3k3cm53eG5qZThPd1V2QTQ2NHpIZ01WTXNHbXgvaUhrbHZoaEt1cFpB?= =?utf-8?B?ellrU2Njd0JkdER0ZTE4VlRzaG12RlZWdDFpZkZ5R2ZET05kZ1QwZjM3cElF?= =?utf-8?B?bS9KK0dOTERvRG5mOGJUQ1ZQL0VWdlZiSkVtb1BPSUlRQUYzbks3ZGtMclE0?= =?utf-8?B?WjdYWEtsZXpQRWlhakl6WEwrQUo0TFNvT2swWWE5QmdIS3pwRHVpNHZkZmJ3?= =?utf-8?B?MHJYYlpJMWZsRWY1QTRzWS9KM3BkbThIWU1uQTY4aWVXTWxzeDVtcDZUZUZP?= =?utf-8?B?bHpRckZPQ0hZWHE2ZEIzcTRXdmM4Z2ZGUWJGZjhsTXRSbUppb1l2WmJIMjdt?= =?utf-8?B?MXdrUXcvM2xpcEZkTzRTblcvdlY0T3VpYk5BMnB2clN1eXhkQzBMS2ZueERo?= =?utf-8?B?MzVNRmJRMzNZb2ZJK2hEbzJYdGp5QTBQdDdVY256Wlo2TmNFemtxRk1FcDNL?= =?utf-8?B?WldkOWMrTzBDWGdKZDdWVHpoU0VWSHFxRzdDUStWalJwY2oyVWQzV1ZEZStv?= =?utf-8?B?b1I4QnRLVytka1ErTjA4eWFQWmJIb1l3V0QrY2QvTDdFb0ppZGFHb3dKZk9R?= =?utf-8?B?VnFSOHRCaytXYXFkczNUWU9JSVQyUmxSSUkzUXNGb2JMMmNKQXpMekVyQ3Yw?= =?utf-8?B?RGtHQTE3UFVFSDNKQnFaTWk3aGZ4Tko0M3lZSFJ3eU5NVk5lSkJ6OUNna2or?= =?utf-8?B?aDZTemN1UC9nT2JpQ0tKSEtyUWxlVkIyS2d1YjVSQ25HNzNPYW0rbVZVMjNk?= =?utf-8?B?Ukh4UWxDMU1OWnVrVi9HZ1dUVUlKYlVjQy9pcm5ucUdJM1k0REdNQUNKcVBs?= =?utf-8?B?MkxGTkNISTFlUkQxaHpaYnJjaGxEVDFlNThOeFBvMnV5QjIzZFBGZlUwT0Mx?= =?utf-8?B?MXc9PQ==?= X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 85eaba68-ff61-4e98-9b6c-08dced3405c7 X-MS-Exchange-CrossTenant-AuthSource: BN0PR07MB8375.namprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2024 16:11:27.2761 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: dVAjhF9ijCVbubzq/g+qstrVtoT1l1iMD/CgTt5FXgn2lJHBOiiBugzthOlq/qL2D52BHjybSiUINnKHeoaqkMxyOHN6xpL+JFKbcnODZ54= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR07MB9082 X-Original-Sender: chris.larson@siemens.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@siemens.com header.s=selector2 header.b=KZgICYSZ; arc=pass (i=1 spf=pass spfdomain=siemens.com dkim=pass dkdomain=siemens.com dmarc=pass fromdomain=siemens.com); spf=pass (google.com: domain of chris.larson@siemens.com designates 2a01:111:f403:c101:: as permitted sender) smtp.mailfrom=chris.larson@siemens.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=siemens.com X-Original-From: Christopher Larson Reply-To: Christopher Larson Precedence: list Mailing-list: list isar-users@googlegroups.com; contact isar-users+owners@googlegroups.com List-ID: X-Spam-Checked-In-Group: isar-users@googlegroups.com X-Google-Group-Id: 914930254986 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Status: No, score=-4.9 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2,RCVD_IN_RP_CERTIFIED, RCVD_IN_RP_RNBL,RCVD_IN_RP_SAFE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: QRy6SUInXXY/ On 10/4/2024 10:20 AM, Christopher Larson wrote: > On 9/26/2024 1:52 AM, Jan Kiszka wrote: >> On 25.09.24 22:27, 'Christopher Larson' via isar-users wrote: >>> I would like to start a discussion about the possibility of supporting >>> OE/Yocto-style features variables within the Isar project. Currently, >>> Isar implements BASE_REPO_FEATURES and ROOTFS_FEATURES, which are quite >>> useful. However, I believe that adding support for DISTRO_FEATURES, >>> MACHINE_FEATURES, and possibly IMAGE_FEATURES would be worthwhile >>> additions to consider. >>> >>> I want to preface this by acknowledging that my perspective is >>> influenced by decades of experience with OpenEmbedded (OE) and OE-based >>> products. I recognize that Isar has a different philosophy, favoring >>> more direct approaches and fewer abstractions compared to OE. >>> >>> That said, I believe the value of these abstractions may justify the >>> added complexity. It seems that many downstreams end up reinventing >>> similar mechanisms for their own needs. For example, CIP adds >>> INSTALL_WIRELESS_TOOLS, USE_CIP_KERNEL_CONFIG, and CIP_IMAGE_OPTIONS, >>> the latter being a list of .inc files required by an image to allow for >>> metadata reuse. Our usage at Siemens includes similar reinventions as= =20 >>> well. >>> >>> Certainly, we could leverage ROOTFS_FEATURES for certain rootfs/image >>> capabilities beyond the existing postprocessing in Isar. Establishing a >>> convention for including optional rootfs/image capabilities could avoid >>> metadata duplication, simplify managing development vs. production >>> filesystems, and provide customization mechanisms for downstreams. >>> >>> Regarding DISTRO_FEATURES and MACHINE_FEATURES, the Yocto documentation >>> covers them in general. The original intention was to allow for a >>> mechanism similar to Gentoo=E2=80=99s USE flags, coupled with OE=E2=80= =99s three >>> orthogonal axes of distro, machine, and image. The intersection of thes= e >>> would control the outcome, allowing any combination to be viable. This >>> results in machine support that is not tightly coupled to distro >>> capabilities or policy decisions, avoiding the pattern of each >>> downstream copying and modifying both distro and machine in a single >>> layer. This decoupling could prevent issues like machines installing >>> packages such as expand-on-first-boot unnecessarily. >>> >>> In OE, the intersection of these features determines certain >>> functionalities. A common example is hardware capabilities like WiFi or >>> Bluetooth, where the distro expresses a desire to support certain >>> functionalities. Only if both the distro and machine support it will th= e >>> required packages be installed. >>> >>> Details would need to be worked out, even if it is determined that this >>> provides more value than it adds in complexity. The core of the global >>> features in OE is their intersection in packagegroup-base, which >>> determines the default installed packages in images built from the >>> ground up. While this doesn=E2=80=99t make sense in Isar with a Debian = base >>> image, there are still optional functionalities requiring package >>> installation. Often, this requires more than just a single >>> IMAGE_PREINSTALL line, so there=E2=80=99s value in having a simpler way= to >>> express a desire to support that functionality. Isar may not need to >>> utilize this functionality directly, but it could be beneficial to >>> provide it for downstream use. >>> >>> Downstreams can and do implement functionality like this if they want >>> to, so I understand the argument for continuing this approach. However, >>> I believe there is value in providing basic functions to utilize such >>> capabilities and documented conventions for doing so consistently. >>> >>> I would love to hear what both Isar core developers and downstream >>> developers think about the possibility of providing a mechanism for >>> using variables like these. I believe that the ability to provide an >>> easier customization mechanism and an abstraction to better separate >>> concerns between the distro, machine, and images would be valuable. It >>> would also ease rootfs customization based on desired system features >>> (distro) and hardware capabilities (machine), if one uses these to >>> adjust ROOTFS_FEATURES. >>> >>> I don=E2=80=99t believe the default behavior of OE=E2=80=99s IMAGE_FEAT= URES, where >>> package lists are defined in FEATURE_PACKAGES_, is worth including here= . >>> It=E2=80=99s not difficult for developers to manually implement package= grouping >>> using features if needed, and it=E2=80=99s often better to create separ= ate >>> packages if multiple dependencies should be pulled in at once. >>> >> >> Thanks for the suggestion. As you mentioned already that you see >> potential to re-model and unify existing public layers with such a >> proposal, how about laying out how those would look like? Would make >> this discussion a bit more concrete, specifically for those of us not so >> long into OE like you are. >=20 > Thanks for all the replies to this, I appreciate the input. I'll start=20 > by considering OE/Yocto's usage of features, options for how to=20 > emphasize their use in isar, my personal recommendation for how to=20 > proceed, and finally look into what the usage would look like in a=20 > specific downstream example as suggested >=20 > To update the status on this, I've been working on a more concrete=20 > proposal to follow-up on the email discussion, as was requested, but=20 > it's not entirely clear as to the best approach. I feel like these are=20 > likely the main options: >=20 > =C2=A0=C2=A0=C2=A0 1. Do nothing, features can be implemented by downstr= eam layers. > =C2=A0=C2=A0=C2=A0 2. Ease use of features by downstream layers, potenti= ally by=20 > creating wrapper functions, or at the least default definitions of the=20 > features variables, and specifically COMBINED_FEATURES. > =C2=A0=C2=A0=C2=A0 3. Enforce more structure on features usage such as t= hrough=20 > inclusion of .inc or .bbclass files the way we have for features in our= =20 > layer and cip has for image options. >=20 > OE/Yocto largely does the second, defining default values, and then=20 > using features in multiple places within the layer. They also provide a= =20 > bbclass to require distro features for a given recipe, and an optional=20 > bbclass to ease use of features through overrides, and the packagegroup-= =20 > base recipe which does not apply for us. Of course, we also don't intend= =20 > to leverage the features within isar itself at this time the way oe-core= =20 > does. >=20 > Wrapper functions tend to be avoided, in large part due to signature=20 > generation. BitBake's checksum generation for task signatures involves=20 > tracking variable dependencies and usage, and has special handling for=20 > bb.utils.contains(), which allows a variable to depend on the presence=20 > or absence of a feature from a features variable, without becoming=20 > dependent on the entirety of the features variable. Wrapping this=20 > function to ease calls would both be an added indirection that I feel=20 > adds an unnecessary abstraction to gain that slight ease of use, it will= =20 > also prevent the signature generation from tracking feature usage fully. >=20 > I also feel that inclusion of a .inc or .bbclass for each feature is=20 > rather indirect, and doesn't align with how isar uses rootfs_features=20 > via a single bbclass extension for multiple features. I think this may=20 > be done by some downstreams, but is a tad too indirect for isar as a=20 > core layer. >=20 > To sum up, I feel that this proposal is largely to encourage the use of= =20 > features variables and to add to the isar documentation to encourage=20 > their use, more than much direct implementation code. I'd think the=20 > following would be a good start: >=20 > =C2=A0=C2=A0=C2=A0 1. Add default DISTRO_FEATURES, MACHINE_FEATURES, COM= BINED_FEATURES=20 > values, even if the first two are empty by default, and the latter=20 > should use inline python to ensure it's the intersection of the first two= . > =C2=A0=C2=A0=C2=A0 2. Add to the docs to encourage use of the features v= ariables, and=20 > specifically the use of bb.utils.contains, bb.utils.contains_any, and=20 > bb.utils.filter, to do so. > =C2=A0=C2=A0=C2=A0 3. Add a test using features to the test suite. > =C2=A0=C2=A0=C2=A0 4. Consider adding a class to ease use of features wi= th overrides,=20 > as this can be helpful when defining many variables which are=20 > conditional on a feature. This should reduce the perceived need for=20 > feature-based file inclusion, I believe. distrooverrides.bbclass in oe-= =20 > core or featureoverrides in sokol-flex could be candidate options to=20 > consider as a starting point. >=20 > As possible options for downstream layers to use features rather than=20 > custom solutions, we can consider possibilities for CIP_IMAGE_OPTIONS.=20 > Rather than isar-cip-core's CIP_IMAGE_OPTIONS listing .inc files to=20 > include, it could add an image extension bbclass which directly defines= =20 > the variables based on ROOTFS_FEATURES or IMAGE_FEATURES, or it could=20 > keep the .inc inclusion and do so based on the features rather than a=20 > new variable. The main benefit there would be consistency rather than=20 > any other concrete benefit, however. >=20 > The benefit of the use of distro and machine I believe would aid in=20 > making the distro and machine less tightly bound, which should ease long= =20 > term maintenance of the downstream layers, but this is difficult to show= =20 > in a trivial example. I'll look into one of the public downstreams to=20 > try a PR as a suggested example. I've gone back over isar-cip-core and looked at its usage of=20 CIP_IMAGE_OPTIONS. Currently the isar core images include any files=20 listed in this variable, but it's only currently set by the swupdate and=20 ebg-swu kas configurations, along with many other variables. Those kas=20 configurations also add swupdate to OVERRIDES directly, which then=20 alters the included feed configurations. So this appears to be a case where we have a global change to=20 configuration, and then multiple corresponding changes to image=20 construction. These sets of configurations in the kas configs are not=20 particularly accessible for those not using kas to build, and the=20 CIP_IMAGE_OPTIONS contents (i.e. "recipes-core/images/swupdate.inc") are=20 difficult to check conditionally for a downstream of isar-cip-core. The=20 kas configs have a number of configurations set, as do the .inc files=20 included by CIP_IMAGE_OPTIONS. This, to me, is a good example of an implementation that would benefit=20 from features, as they provide a way for the user to enable=20 functionality whether via kas or otherwise. As pointed out by Cedric,=20 the features list also functions as documentation, in that=20 ROOTFS_FEATURES and IMAGE_FEATURES help describe the behavior of an=20 image, and could potentially be included in a file in the image to help=20 determine image behavior and contents after the fact. It also makes it=20 easier for a downstream to alter the image further based on the enabling=20 of the feature, as it's trivial to bbappend or add an image class that=20 acts when a given feature is enabled. Admittedly, most downstreams would=20 provide their own images, but this would provide a pattern they could=20 follow as well, which would increase consistency between the layers. To handle the global configuration change (feeds added, etc), either we=20 could operate conditionally on IMAGE_FEATURES globally, but this assumes=20 it's not allowed to be different on a per-image basis, which isn't=20 typical, or one could add a DISTRO_FEATURES +=3D "swupdate" and then=20 conditionally operate on this elsewhere rather than using a custom=20 override, and then potentially enable the image feature by default based=20 on this distro feature. This does add an indirection, but I think the value of having easy to=20 set and check lists of features for 1. documentation, 2. ease of use for=20 enabling/disabling, and 3. easy to act on conditionally in a downstream,=20 makes it worth the indirection. This is one of the simpler proof of=20 concept areas I could find that still shows the value. It's not entirely clear to me which settings in the swupdate.yml and=20 ebg-swu.yml are appropriate for always enabling based on the feature vs=20 being provided as examples the user is expected to override, so I didn't=20 move forward with the PR just yet. --=20 Christopher Larson Siemens AG www.siemens.com --=20 You received this message because you are subscribed to the Google Groups "= isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to isar-users+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= isar-users/5ddf60dc-f297-4d5f-9de2-837fdd0e7e75%40siemens.com.