[OE-core] [RFC PATCH 0/6] Kernel configuration check for recipes

Paul Eggleton paul.eggleton at linux.intel.com
Mon May 9 20:55:29 UTC 2016


On Mon, 09 May 2016 08:08:55 Bruce Ashfield wrote:
> On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
> 
> paul.eggleton at linux.intel.com> wrote:
> > Add the capability for other recipes to verify that kernel
> > configuration options they depend upon at runtime are present, and warn
> > if they are missing. This seems functional enough to me but is still in
> > RFC - please let me know if it looks OK to you or I've missed anything
> > (no doubt there are recipes we could add the checks to, I refer mainly
> > to the mechanism itself).
> > 
> > 
> > Please review the following changes for suitability for inclusion. If you
> > have
> > any objections or suggestions for improvement, please respond to the
> > patches. If
> > you agree with the changes, please provide your Acked-by.
> 
> See my replies to the patches. I'm sure it won't matter in the end, but
> this is a duplication of the mechanisms that we already have in the kernel
> config check phase. I have a whole set of changes that I completed early
> this year that extends that mechanism to any kernel (not just kernel-yocto)
> classes. In that mechanism there's the concept of "required" and
> "optional" Kconfig options. If they aren't present in the final .config, we
> warn and optionally error (this is versus the currently mechanism of only
> warning if boot critical options are dropped).

OK - so I guess this gets down to the question of whether we can practically 
define all of these userspace dependencies on the kernel side rather than 
individual recipes. I actually couldn't tell you how many other recipes this 
might be useful in - systemd and udev are where it's come up numerous times 
for users, and IMAGE_FSTYPES was one that I could think of. Perhaps we ought 
to analyse that in greater detail before proceeding.

> I'm betting that the follow on to this series will be "Hey recipes should
> set the options for the kernel if they really need them" .. which IMHO is an
> incredibly bad idea.

We'll never be getting to that level. Fundamentally one recipe cannot 
influence the configuration of another, at least not directly, and I agree in 
this case it wouldn't make any sense. I'm just proposing a check here.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



More information about the Openembedded-core mailing list