From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6514350167115694080 X-Received: by 10.28.87.194 with SMTP id l185mr3126402wmb.9.1517315987055; Tue, 30 Jan 2018 04:39:47 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.223.191.3 with SMTP id p3ls846102wrh.2.gmail; Tue, 30 Jan 2018 04:39:46 -0800 (PST) X-Google-Smtp-Source: AH8x224a6Q7qMAtkT0P5qLNaw/kcct97R7Psi7ff65/YotfT9R+a/bif2v21mQKJ4+S1kDhNNwTG X-Received: by 10.28.48.88 with SMTP id w85mr3195154wmw.30.1517315986494; Tue, 30 Jan 2018 04:39:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517315986; cv=none; d=google.com; s=arc-20160816; b=NGZMliQ/piWBiz8I6RdNtJD+z8seg9HG5cDNjT2dLkCvAsZg8+mrAC7phkkqaUgrDd VZjUY75EaP5FA6uvx46B+CzYFzGbCYfzPeTCEu9JnpNtb5GhWI/Z+V1S26LP6cyeNLqP WHnrUFkdA9OrH50dGW7WERc7OWhYtPaqATAV2jnsRP55AOrgM7QlNp6gpAn6Pf0PUAZQ NYQMm25l7+e5LyZCd2OHt8WlN7vJmUqzWPi7boxRZ1wO2E+UuvcJQibrxBsJueqZmq9i Y810ECgoXZAPxkJzLINaCE/WRlyAo6RAlDS9O7N9VLqhyVs5OPNAJdjqacRLtfcPUmoQ Wzdg== 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=QveaQlWWosOibM5FxGJ+RXeRQ7OZFE7T4coQ9kJ0gUE=; b=CxTfS+6InmyrSuJUOsGI8QkF70ggo99+QhJmEhZEiybEt0YOVFR9BL8FDI168FyAcs bM/DxX+G5NjWToKLQ1RgdUnQ6Edjt2bg28e0VT+g3Go3jWWYXnLvvhUzueqA267DtUVa 3aw95xJOaEdXXt3NRuSqM4YYn4rz3YtSyoJ3c5fFk6efhdKFukZeebE17DNeOeYDd6Ur S0yRZNnJjqAATCILpYv1g4HNrAUc64a/Y6WZ75UL1aowTOahn0WXN1QIuY1k6/I9zOHN EwVTO33Yv+cVAk+zMPJMCfkx8N/8Vre9iS6F0uK3Pph7OxX+UbBzuvComvGIyt0Nu7RI bgCg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id d8si140868wmf.1.2018.01.30.04.39.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2018 04:39:46 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id w0UCdk2d022101 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 30 Jan 2018 13:39:46 +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 w0UCdjlH001488; Tue, 30 Jan 2018 13:39:45 +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> From: Jan Kiszka Message-ID: <32b51580-2c52-1e98-13fb-7fc875fe313e@siemens.com> Date: Tue, 30 Jan 2018 13:39:44 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: 2yAz5T2LrQin 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. > > 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. > >> - 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. > > 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. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux