From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6514350167115694080 X-Received: by 10.28.184.88 with SMTP id i85mr3062334wmf.22.1517314024520; Tue, 30 Jan 2018 04:07:04 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.202.2 with SMTP id a2ls428673wmg.8.canary-gmail; Tue, 30 Jan 2018 04:07:04 -0800 (PST) X-Google-Smtp-Source: AH8x225dRR+SRyrk9hrS3fxmkFnn2eUHDvfEstUCCsxzUeu1s1b1c4a5MyzdV29B49tsnnhR5Ras X-Received: by 10.28.3.11 with SMTP id 11mr3112634wmd.4.1517314024079; Tue, 30 Jan 2018 04:07:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517314024; cv=none; d=google.com; s=arc-20160816; b=KNa5xbH4N2/oblFOEXdJzFBqIueOoQIKJi9XIm2vbRF2fbrz9Onvp8ETvG6Esc5Yq1 2/NRVLgGCoz9WZE/d5BH2P07HeuacG33uzAXTTxSWqNxQUwehAe1PCDQX+O3Hv2OjOkF NNgiKG4FOorwdex2YdWB87KOwhrTC+n/0gaOYcQPauExc/oFp9ZsZ/3XsQx8Z9yoVCkV 2gGrDNG7CyBbtE/fGsGjH9oFd7rS4YyOyZR5tu8QYvLJ0EtFo6maXWyEzqyw+9ELdQgI tVF9ZmhuoWazKiQYW0+QQ6p033fKqlHZ3wipbOrz/vMKN4mpBAuMhApfDk5yl3WICf1J QHTg== 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 :arc-authentication-results; bh=0GUKYHFldohpObZ3qe/YxvRKA/e9neuvujDTYW2sp+c=; b=Gxlr5Lm1Nzic6MQ9brQTx6gagH4vVccjsX9LRxLNLEufjbU47Al09pmBVJfvTEygV0 cQtNhta2wtcNtptRwCWx64jD+4cU9MEUacS1H6M3DixHR2k/zv13WtxUO0MhA0yRkjbp FNTH4gOwgJeihBvAzBRo+mGqWLhf28717ohXCApPaG9OqnHQgCJGt1bTaWpnjqKj7W+u vNHozIlpMRi9dcX/9Ih7kGZhwGwIUG6T8f7JNJMxumCwImdMGgHfjICjVpuTha0ubV0w InYbNn6ZLhezwcfQw/Q00QXNYfPKSlBCGHJyXvxYdiSkAN4AbQfNXvFVJmcQcXygbHNU GoQA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id k21si1426090wrd.1.2018.01.30.04.07.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2018 04:07:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: best guess record for domain of asmirnov@ilbers.de designates 85.214.62.211 as permitted sender) smtp.mailfrom=asmirnov@ilbers.de Received: from [10.0.2.15] ([188.227.110.165]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w0UC711L004598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 30 Jan 2018 13:07:02 +0100 Subject: Re: [PATCH v2] Install kernel via replaceable recipe To: Jan Kiszka , isar-users References: <4ab8a0f9-9a34-0e20-bfe0-a447ffe134f6@siemens.com> <70d3096b-ecb4-ab4c-5361-f63b80961c32@siemens.com> <978b75b5-b6ae-6d2d-3589-0515cba06ba3@ilbers.de> <698f0c31-02ee-1682-4b34-29d26684f1f0@siemens.com> From: Alexander Smirnov Message-ID: Date: Tue, 30 Jan 2018 15:06:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <698f0c31-02ee-1682-4b34-29d26684f1f0@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: iX3psX6hWP+N On 01/30/2018 02:25 PM, Jan Kiszka wrote: > On 2018-01-30 12:06, Alexander Smirnov wrote: >> On 01/30/2018 01:52 PM, Jan Kiszka wrote: >>> On 2018-01-30 11:49, Alexander Smirnov wrote: >>>> On 01/30/2018 12:34 PM, Jan Kiszka wrote: >>>>> From: Jan Kiszka >>>>> >>>>> This simplifies the common task of using a custom kernel instead of the >>>>> pre-selected debian variant: Move the kernel installation into a dummy >>>>> dpkg-raw recipe that only has the kernel package as dependency. >>>>> >>>>> Which recipe is used for providing the kernel can now be selected via >>>>> the well-know PREFERRED_PROVIDER_virtual/kernel, just like in OE. >>>>> >>>>> The kernel package name is communicated from the target multiconfig >>>>> file >>>>> to the linux-debian recipe via the DEBIAN_KERNEL variable. >>>> >>>> Why it's Debian kernel? This could be a bit confusing, Isar doesn'y >>>> support only official Debian kernel. For example Isar already supports >>>> Raspbian which contains its own Raspbian kernel. >>> >>> I'm always open for better name proposals. >> >> So, if no reasons, I'd propose: >>  - KERNEL_PACKAGE >>  - KERNEL_PACKAGE_NAME >> >> >> [...] >> >> >>>>> +inherit dpkg-raw >>>> >>>> Do I understand correctly, that this recipe creates fake package that >>>> has dependency from the upstream kernel? So in target rootfs 2 kernel >>>> packages will be installed? >>> >>> Right, one empty linux-debian meta package and the real one. The former >>> allows us to trivially kick out the latter in favor of a custom kernel. >>> >> >> What is the benefit of this complexity? > > It's not complexity, it's simplification and cleanup over the current > hard-coding approach. > >> If we need to have over-writable >> kernel name, it would be enough to pass current DEBIAN_KERNEL variable >> directly to IMAGE_INSTALL. The same result, but no extra recipe in Isar >> tree and no pseudo package in target rootfs. > > There are several disadvantages with your approach: > - you need to encode the concrete package name instead of just defining > an abstracting provider Nothing extra, you already do this in your patch like: +DEBIAN_KERNEL ?= "linux-image-armmp" Eventually your abstract provider already contains hardcoded package name. > - you need the same thing for linux-headers (which I'm currently very > interested in as I need to build against the kernel) This is not clear for me, how headers will be installed from this pseudo package. How I could enable/disable headers installation. > - it deviates from the bitbake pattern of PREFERRED_PROVIDER For me it doesn't look like preferred_provider pattern. According to the bitbake manual: 8<-- Sometimes a target might have multiple providers. A common example is "virtual/kernel", which is provided by each kernel recipe. Each machine often selects the best kernel provider by using a line similar to the following in the machine configuration file: PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" 8<-- So it's assumed that there are several providers for the same stuff, i.e. several *physical* recipes, and in your machine config you select the preferred provider, i.e. the name of *physical* recipe. In current patch there is only one physical provider which contains per-machine hardcoded kernel name. So, none of proposed approaches here (including my one) really implements PREFERRED_PROVIDER pattern. To follow it, we need to have recipe for each kernel instance. Alex