All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: Tom Zanussi <tom.zanussi@intel.com>,
	Otavio Salvador <otavio@ossystems.com.br>,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [RFC PATCH 6/6] classes/image: check kernel config supports IMAGE_FSTYPES items
Date: Tue, 10 May 2016 08:45:27 +1200	[thread overview]
Message-ID: <2777859.s7KusZZa7x@peggleto-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <CADkTA4MGn2Ju0X-AKeyOJ0ba-kZ6v8XGDr2JcPk5zXWADzyMnA@mail.gmail.com>

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


  parent reply	other threads:[~2016-05-09 20:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09  4:43 [RFC PATCH 0/6] Kernel configuration check for recipes Paul Eggleton
2016-05-09  4:43 ` [RFC PATCH 1/6] classes/kernel-check: add a class to check kernel config options Paul Eggleton
2016-05-09 11:59   ` Bruce Ashfield
2016-05-09 20:53     ` Paul Eggleton
2016-05-09 21:00       ` Bruce Ashfield
2016-05-09  4:43 ` [RFC PATCH 2/6] eudev: check for required " Paul Eggleton
2016-05-09  4:43 ` [RFC PATCH 3/6] systemd: " Paul Eggleton
2016-05-10  0:31   ` Khem Raj
2016-05-09  4:43 ` [RFC PATCH 4/6] classes/kernel: fix typo Paul Eggleton
2016-05-09  4:43 ` [RFC PATCH 5/6] classes/kernel: check OLDEST_KERNEL at configure time Paul Eggleton
2016-05-10  0:33   ` Khem Raj
2016-05-09  4:43 ` [RFC PATCH 6/6] classes/image: check kernel config supports IMAGE_FSTYPES items Paul Eggleton
2016-05-09 12:05   ` Bruce Ashfield
2016-05-09 16:57     ` Christopher Larson
2016-05-09 19:35       ` Bruce Ashfield
2016-05-09 20:45     ` Paul Eggleton [this message]
2016-05-09 20:58       ` Bruce Ashfield
2016-05-09 12:08 ` [RFC PATCH 0/6] Kernel configuration check for recipes Bruce Ashfield
2016-05-09 20:55   ` Paul Eggleton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2777859.s7KusZZa7x@peggleto-mobl.ger.corp.intel.com \
    --to=paul.eggleton@linux.intel.com \
    --cc=bruce.ashfield@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=otavio@ossystems.com.br \
    --cc=tom.zanussi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.