Re: [PATCH v2] Install kernel via replaceable recipe

[Alexander Smirnov <asmirnov@ilbers.de>]

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 <jan.kiszka@siemens.com>
>>>>>
>>>>> 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