Re: [PATCH v2] Install kernel via replaceable recipe

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

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