From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6514350167115694080 X-Received: by 10.28.30.68 with SMTP id e65mr3389593wme.17.1517502031999; Thu, 01 Feb 2018 08:20:31 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.28.31.200 with SMTP id f191ls47787wmf.5.canary-gmail; Thu, 01 Feb 2018 08:20:31 -0800 (PST) X-Google-Smtp-Source: AH8x225mkx5cj+kXSfBX7X0p4M3QoixBNk6waQK4GrMA+s4WCIn/9nXASEaGu6gOvO580Exo4FUP X-Received: by 10.223.156.210 with SMTP id h18mr4018400wre.1.1517502031392; Thu, 01 Feb 2018 08:20:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517502031; cv=none; d=google.com; s=arc-20160816; b=XgZEwd4w2yBCjn/KH/DjNwO+aET3CTsD20VG2LAoeBagneYJ2bYwwV9zm59jLdi/o/ OFLWvKrUkDvn75iNVO8h6Qb5L0Kp+J3iV6pPnxg4qAUt3RwvPx28KN0kOXTeYDNsH4X9 220Q+eREoB2K/aSB3E+6VBbRFa7PQ8E6QHszhCGLGOZQVn7nG5EXob4nSwsGSSdCj7oC OQjcTZk3tUJG4TKgvuPlsUSCBns/M2nrDJgUG/g+/elNmMSila1HnLh1/CUTWmICNNTF 3hh+8/qqMgLH0zzLTKVLiXGe4AK7VO2KNffcaOpqb2FxwG/tIynTr3WXB37DOfxcqQCa LLKg== 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=36FOMHpXfm0Zu+oYzC0qonL5xWN5HWocPa3yVB4anbM=; b=cfeDu1G9Z6stIEa5/6t9DQyboUTj3vja2pgNTmFWtVL0XLK2T9bjmUgV2Eh+HDhq27 nrSC8pxkwFJraSjIQ8pS32KU6+sbsFUCHC00ABLKuoKzD7eEWKriQuZ23ViR4P3BvPa5 TmMlCq5ghdGW1lioghUWpugGDOci9Ur43H1eiEjMqYEYu6Nz4iopfv227bp1klmydEbh 5VnwABHnnCbgQwTosVVKTsmXqFubTLLfyDNqBQ2mekl+NsXW++5PD7Q9M0+G3IH0QXY4 eRiU0iOJU4IklZI3G4oPTwdU0qNum/oAmW1hQlzC8v/QqB3piqpHdRzyClqKcFZlGR8J w81g== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id v8si204842wrg.2.2018.02.01.08.20.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Feb 2018 08:20:31 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w11GKUeJ008117 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 1 Feb 2018 17:20:31 +0100 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail1.siemens.de (8.15.2/8.15.2) with ESMTP id w11GKUEk009063; Thu, 1 Feb 2018 17:20:30 +0100 Subject: Re: [PATCH v2] Install kernel via replaceable recipe To: Alexander Smirnov , 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> <49175281-e41a-1290-4e37-31301c4ecdd3@ilbers.de> From: Jan Kiszka Message-ID: Date: Thu, 1 Feb 2018 17:20:29 +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: <49175281-e41a-1290-4e37-31301c4ecdd3@ilbers.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: 4S//KfAPEFrB On 2018-01-30 13:57, Alexander Smirnov wrote: > 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? Then we would need to create a bitbake recipe for each variant of distro kernels - does not scale. The reason is that PREFERRED_PROVIDER encodes a recipe, not a debian package. > >> >>> >>> 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. :-) It mostly working now, just need to refactor the variables again because of DISTRO_ARCH != DISTRO_KERNEL_ARCH. The latter is needed in multiple places. Maybe I will find some time during FOSDEM, otherwise next week. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux