Re: [PATCH v2] Install kernel via replaceable recipe

[Jan Kiszka <jan.kiszka@siemens.com>]

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 <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"

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