[OE-core] [RFC PATCH 6/6] classes/image: check kernel config supports IMAGE_FSTYPES items

[Bruce Ashfield]

On Mon, May 9, 2016 at 4:45 PM, Paul Eggleton <paul.eggleton at linux.intel.com
> wrote:

> Hi Bruce,
>
> On Mon, 09 May 2016 08:05:06 Bruce Ashfield wrote:
> > On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
> > paul.eggleton at linux.intel.com> wrote:
> > > A lot of the IMAGE_FSTYPES items require the appropriate filesystem
> > > driver to be enabled in the kernel configuration; e.g. in order to read
> > > a btrfs filesystem, the kernel must enable CONFIG_BTRFS_FS. Add a check
> > > to ensure that is the case.
> >
> > So what's the overall design for this ? Is it documented anywhere ? This
> is
> > something that we talked about a couple of years and I have reservations
> and
> > objections to the current implementation.
> >
> > .. but since I can only see bits and chunks of patches, I'd rather read
> > something complete and offer some more detailed feedback.
> >
> > Bottom line: I see a slippery slope to tightly specified option that
> depend
> > on kernel versions, I see kernel options sprayed all over layers, etc,
> etc.
> > Which is exactly what we've been trying to avoid with the centralized
> kernel
> > meta-data, and again, there's a mechanism that I finished early this
> year to
> > extend those options to any kernel, enforce, warn, error, etc .. but now,
> > I'll just toss it into the bin.
>
> There's no design written out beyond what you see in the associated bug:
>
>   https://bugzilla.yoctoproject.org/show_bug.cgi?id=5574
>
> The situation I am trying to avoid is the exact one mentioned by a
> commenter
> on that bug - which is that if I build my rootfs in a particular way, and
> couple it with a particular kernel configuration, I want the build system
> to
> tell me if those are going to be incompatible. The current situation where
> the
> you don't find out until the system doesn't boot (and you may not get any
> meaningful error message at that point anyway) isn't great.
>
> You mention hardware in your reply to Chris, but this mostly isn't about
> hardware - it's about dependencies on software features of the kernel from
>

I only brought up h/w to point out the slippery slope, and that if you are
going to
solve one class of options, eventually it will lead to someone asking for
others
and then the ability to set them. We then have a tight binding and
distributed
knowledge of the kernel specifics.


> userspace. I'm perfectly happy if we go for alternative solution, but to my
> mind whatever solution we come up with needs to be something whereby if you
> enable something in userspace that the kernel as currently configured isn't
> going to be able to support, you at least get a warning at build time.
>

What you describe is almost exactly what KERNEL_FEATURES + the existing
Kconfig
audit does. That mechanism does the audit for software and h/w features via
a level
of abstraction (the name of the feature, versus the kernel options
themselves).

I'm about 75% of the way to extended that to any kernel (not just
linux-yocto) and
exposing the "required" and "optional" kconfig support (that has been
around for
about 1.5 years .. just no one has asked for it :D

That's why I'm trying to understand what exactly is missing and is being
solved
here, so I can decide whether to drop my changes or not.

Bruce


>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160509/2f09df15/attachment-0002.html>