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

[Paul Eggleton]

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

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre