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

[Bruce Ashfield]

On Mon, May 9, 2016 at 12:57 PM, Christopher Larson <clarson at kergoth.com>
wrote:

>
> On Mon, May 9, 2016 at 5:05 AM, Bruce Ashfield <bruce.ashfield at gmail.com>
> 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.
>>
>
> Perhaps this functionality should be by feature or capability rather than
> individual options, and let the kernel build determine what features it
> provides based on its configuration.
>

You hit the nail on the head with that comment. There are some old bugzilla
lurking around
about distro -> kernel options (aka kernel features) that I've suggested a
similar concept
(or even machine features -> kernel).

IMHO some level of abstraction is needed for both, since otherwise we end
up tightly
coupling recipes to a machine and kernel combination.

Someone can ask for a specific option all they like, but unless they know
the details
of the kernel provider .. they are basically making a guess, and someone
working with
many different types of recipes shouldn't have to know the details of every
kernel tree
they are building. Sure it isn't widespread, or a lot of recipes, but again
.. I see a slippery
slope.

In the case kernel doesn't have it they fail (or if they've specified
something wrong), but
there are often substitutions that can be performed .. or optional
features, etc.  If there's some
level of abstraction, the kernel provider itself can turn on the right
options, avoid common / minor
errors, make suggestions and ensure that the h/w (and kernel) actually has
the capability.

The h/w actually having the capability is a significant issue for me as
well, since asking for
something .. but not actually having the required h/w (or arch) support,
and having no way
to abstractly figure out if something is supported .. means that even more
knowledge of
the kernel and the machine starts slipping into recipes and ends up being
spread all around
the layer stack.

Cheers,

Bruce




>
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
>



-- 
"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/6cdc8e45/attachment-0002.html>