Re: [PATCH v2] Install kernel via replaceable recipe

[Alexander Smirnov <asmirnov@ilbers.de>]

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?

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

Alex