From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) by mail.openembedded.org (Postfix) with ESMTP id AA68B60721 for ; Mon, 9 May 2016 19:35:24 +0000 (UTC) Received: by mail-oi0-f42.google.com with SMTP id x201so222832912oif.3 for ; Mon, 09 May 2016 12:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/CfWXlUc5q5WCu2z1Ro7QGqy8LEG2Da9GlJemRWA/Ng=; b=CTzrxDgycmgoY3RdCggcfx5v6HMwyNaTiVK2vNFrUg/S00rUerZ+o5CaK1ittfR/hN Id+dWFvgfnNHIRKJw3QDu5/8h7lrp7LvAWb1pkpHd6Q4c+xK8mUl+0MTe3T64BMaOOIw Qin8jtg1YsCekfa7ds/AhZh6AkbOxd07/SiJQDutYVGXL4rAeOO3fAVl/+9CvTGPAmsi S/APxVrKEoD539AjJUdCLZ4HIl9E630pRHqyNlBgLWXpOu7K8/jHBqdP4+k3pdKXefem kioArSer49+dDOf+tmE4BnM2P/fFuJwpK7L+MxC+kTbP8iV8p8ddmC1bXuK7cS5QtjIg Wgkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/CfWXlUc5q5WCu2z1Ro7QGqy8LEG2Da9GlJemRWA/Ng=; b=E/g0xqSsART0m1pWTregDQXIhC59VPtUzzLcn2Q5k737VVdBoph25kk4sEX3MnTWLg iMdMykmM3I1Ed8WvuJkEJMywJrjDGewuCEMfWT1jdzDJSdmpFI1S6x1wMKhZhYc1qj40 YNM+wFIO2eo65BbZq3ZPxSHz7kmhnN+pyfrkjz2cG/He0HfBKkqSD3U8exA+oXHmOh9n pL7LQBuybuCo6Kj43iUW1/q+TnVT3X2AmdIHm4VYX5L8b2ycDUQvgX+4ETNWBtrAeawe 2cqu7/ikQ7plO4gGoiBaVP+3hzo9axRc5qns0XGO+mw0/MAaxrXsy22mdma0ALeGNS2B jUHQ== X-Gm-Message-State: AOPr4FUPHYPzXktM28XehWY8yVrR/0LqzUA+w5EFRCjFuXVtGKj93c+slek2mvLxn5MwYpF4EgaJSECp122llQ== MIME-Version: 1.0 X-Received: by 10.202.46.139 with SMTP id u133mr15933045oiu.16.1462822525443; Mon, 09 May 2016 12:35:25 -0700 (PDT) Received: by 10.157.32.135 with HTTP; Mon, 9 May 2016 12:35:25 -0700 (PDT) In-Reply-To: References: <29259d2220b8e6e577a3efaa160b77e3366fb6d5.1462768634.git.paul.eggleton@linux.intel.com> Date: Mon, 9 May 2016 15:35:25 -0400 Message-ID: From: Bruce Ashfield To: Christopher Larson Cc: Paul Eggleton , Patches and discussions about the oe-core layer , Otavio Salvador , Tom Zanussi Subject: Re: [RFC PATCH 6/6] classes/image: check kernel config supports IMAGE_FSTYPES items X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 19:35:25 -0000 Content-Type: multipart/alternative; boundary=001a1137c99cffa67c05326de8fa --001a1137c99cffa67c05326de8fa Content-Type: text/plain; charset=UTF-8 On Mon, May 9, 2016 at 12:57 PM, Christopher Larson wrote: > > On Mon, May 9, 2016 at 5:05 AM, 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. >> > > 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" --001a1137c99cffa67c05326de8fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, May 9, 2016 at 12:57 PM, Christopher Larson &= lt;clarson@kergoth= .com> wrote:

On Mon, May 9, 2016 at 5:05 AM, Bruce Ashfield <bruce.ashfield@g= mail.com> wrote:
On= Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <paul.eggleton@l= inux.intel.com> wrote:
A lo= t 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.


<= /span>
So what's the overall design for this ? Is it documented any= where ? This is something
that we talked about a couple of years = and I have reservations and objections to=C2=A0
the current imple= mentation.

.. but since I can only see bits and ch= unks 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 fini= shed early this year to extend those options to any
kernel, enfor= ce, warn, error, etc .. but now, I'll just toss it into the bin.
<= /blockquote>

Perhaps this functionality should be by featur= e or capability rather than individual options, and let the kernel build de= termine what features it provides based on its configuration.

You hit the nail on the head with that comme= nt. There are some old bugzilla lurking around
about distro ->= kernel options (aka kernel features) that I've suggested a similar con= cept
(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 combinat= ion.=C2=A0

Someone can ask for a specific option a= ll they like, but unless they know the details
of the kernel prov= ider .. they are basically making a guess, and someone working with
many different types of recipes shouldn't have to know the details o= f every kernel tree
they are building. Sure it isn't widespre= ad, 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 su= bstitutions that can be performed .. or optional features, etc.=C2=A0 If th= ere's some
level of abstraction, the kernel provider itself c= an turn on the right options, avoid common / minor
errors, make s= uggestions and ensure that the h/w (and kernel) actually has the capability= .

The h/w actually having the capability is a sign= ificant issue for me as well, since asking for
something .. but n= ot actually having the required h/w (or arch) support, and having no way
to abstractly figure out if something is supported .. means that ev= en more knowledge of
the kernel and the machine starts slipping i= nto recipes and ends up being spread all around
the layer stack.<= /div>

Cheers,

Bruce
<= br>

=C2=A0

--
Christopher Larson
clarson at kergoth dot c= om
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
= Senior Software Engineer, Mentor Graphics



--
"Thou shalt not follow the NULL pointer, for chao= s and madness await thee at its end"
--001a1137c99cffa67c05326de8fa--