From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6514350167115694080 X-Received: by 10.107.145.197 with SMTP id t188mr19385145iod.72.1517317070107; Tue, 30 Jan 2018 04:57:50 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.107.151.145 with SMTP id z139ls684879iod.9.gmail; Tue, 30 Jan 2018 04:57:49 -0800 (PST) X-Google-Smtp-Source: AH8x2277U6GvSX4kyK8x70cOwy9M+BKJaLnuaG86bW7uqhWKkO3XxCgFoRmbeO3pGlNHcLUJh4Ne X-Received: by 10.107.134.102 with SMTP id i99mr20091889iod.8.1517317069612; Tue, 30 Jan 2018 04:57:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517317069; cv=none; d=google.com; s=arc-20160816; b=AB0clo7e0Wyzl12xcG53yc+571epvydjV4mACXFWBwkmQLv0bbpGAOUS1u+HnZz5SL bns8FPlAilAg40sVCzPBdfoGh5EpBP5HMfj3Jm8KUpO+2YW0rkXPRF2o0TvIBo99rFyI wjWAIqmVauERw1IyxyJqfVtlnt+RydXsp2KiHAhiwIV+FYW/bPEP9XN9wxgACzNnrzFH qJh3POSnn782mcLapoU8oUDAaiuZ6tbHSPLm7DbdN2V/fh/jrzs5WwYINcgXron5LXIH Y1xAWc+oC+sX7iGIBO4OJeMMEyOU/i/QoOOCL0etUPNfFix+lWXSJu9NJ8eQzfETADcD a16g== 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=XoJVNGweBqT5lCh+n5NNH2DiLiHWnYp0I65RGmmVDfk=; b=j7RkqGlsgoCGpa6RUObCFxNmvU7Jf0JLMsEo+A+DBzyvVKI/f+MUE9xlr5PZAHDT/P rCABeJ7CgnNFN+61+YXQiBXkWdxy6MFsuGxVy5QrL1seVIpSEMoIyE/MmfW7Zq+c/j0k df0Ge2PBXfAt9aJ8xOhaFJ7DIRmrmHWOboez7WVXKmWfwAA1XicbuDxFhKhugqp4vMzn hOz58PBOvQiJkyrr7H2jI95frPzqI7P6xADQEoKd+zGCkXVwPsRyv4XusiPaYIA22jox NLdUhCA6pUs+eRuo83wN7A3AQZUklQ5IHTCmd/EsrqmpEN5IVsNdLmR6jqV6haD9EGMh Paug== 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 66si1120435itr.0.2018.01.30.04.57.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2018 04:57:49 -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 w0UCvibZ004709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 30 Jan 2018 13:57:46 +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> <32b51580-2c52-1e98-13fb-7fc875fe313e@siemens.com> From: Alexander Smirnov Message-ID: <49175281-e41a-1290-4e37-31301c4ecdd3@ilbers.de> Date: Tue, 30 Jan 2018 15:57:39 +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: <32b51580-2c52-1e98-13fb-7fc875fe313e@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: xI/Xqe1/QrR3 On 01/30/2018 03:39 PM, Jan Kiszka wrote: > On 2018-01-30 13:06, Alexander Smirnov wrote: >> 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" > > That defines the distro-specific binary kernel. Ideally, you do not mess > with it as user. My question, why can't you pass this directly to image if you already have it hardcoded? > >> >> 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. > > Headers should normally go only into the buildchroot. Basically, the > alternative recipe will take care of providing a different package which > Provides: linux-headers, fill that into the local repo and, thus, > override the upstream package. Not yet tested, I have to admit, but it's > the current plan. Ok, it would be interesting. > >> >>> - 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. > > Exactly. I have some exemplary linux-mainline_4.14.bb and > linux-cip_4.4.bb here under test. Or you add some linux-hacky-vendor.bb > if needed. Then set the preferred provider accordingly. Yes, I understand this model, it's ok. But this doesn't explain the need of pseudo recipe for upstream kernel. It would be more logically correct in bitbake philosophy to pass the upstream kernel name directly to PREFERRED_PROVIDER: PREFERRED_PROVIDER_virtual/kernel = "linux-image-armmp" PREFERRED_PROVIDER_* eventually is passed directly to list of debs to install via multistrap, so could shortcut this without pseudo 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. > > Stay tuned for having a second user of that feature in-tree soon. > For sure, it would be nice to have it in Isar. :-) Alex