Re: [PATCH v4] Add recipe for linux kselftest

[Baurzhan Ismagulov <ibr@radix50.net>]

Hello Vijai Kumar,

On Tue, Mar 30, 2021 at 02:41:08PM +0530, vijai kumar wrote:
> Just had a look at that series. Seems like we backport the necessary
> patches for the particular kernel version.
> This might be hard here, since the changes might me more.
> 
> The original intention to have this package as a separate recipe is to
> provide means to use the latest kernel
> kselftest testcases. Those seem to be more mature than one available
> in lower kernel versions like 4.19.
> 
> The changes might be too much to backport making the approach more complicated.
> 
> In our usecase we are using the cip kernel, and if someone feels like
> some testcases needs to be backported,
> it needs to be done in the cip-kernel project and not it ISAR. But
> there is no strong requirement from the users
> for that, they are just okay with using the version that is available
> in the latest kernel. This recipe just makes them
> achieve that.

So, this is a trade-off.

On one hand, architecturally it would make sense to bundle all binary packages
in the same source package. The advantages would be avoiding code duplication,
avoiding fetching different kernel sources in case the two are different
(better build time and space efficiency).

On the other hand, separate tool recipes allow shipping the latest tools also
for older kernels. The advantages are independent kernel and tool versions if
different ones are used, avoiding building the kernel if it isn't needed
(better build time and space efficiency).

Personally, I could live with this implementation until we have a better one.
We will play with it and let you know. That said, I still think that in
general, we should strive for "one source -- one recipe" implementation and
find a good way to refactor this one.

Supporting older kernel versions is an important feature; we should be looking
how to support newer ones without creating a mess. If necessary, maybe we could
split the include file into epoch-specific ones (linux-4.19+.inc,
linux-5.4+.inc, etc.). I don't mind if we override upstream packaging
mechanisms in part or even fully for the old versions; for the newer ones, I
agree that we should at least try submitting our changes upstream. Regarding
partial builds, maybe we could have a var choosing which components to build if
e.g. the kernel itself is not necessary.

With kind regards,
Baurzhan.