<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 9, 2016 at 12:57 PM, Christopher Larson <span dir="ltr"><<a href="mailto:clarson@kergoth.com" target="_blank">clarson@kergoth.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Mon, May 9, 2016 at 5:05 AM, Bruce Ashfield <span dir="ltr"><<a href="mailto:bruce.ashfield@gmail.com" target="_blank">bruce.ashfield@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <span dir="ltr"><<a href="mailto:paul.eggleton@linux.intel.com" target="_blank">paul.eggleton@linux.intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A lot of the IMAGE_FSTYPES items require the appropriate filesystem<br>
driver to be enabled in the kernel configuration; e.g. in order to read<br>
a btrfs filesystem, the kernel must enable CONFIG_BTRFS_FS. Add a check<br>
to ensure that is the case.<br></blockquote><div><br></div><div><br></div></span><div>So what's the overall design for this ? Is it documented anywhere ? This is something</div><div>that we talked about a couple of years and I have reservations and objections to </div><div>the current implementation.</div><div><br></div><div>.. but since I can only see bits and chunks of patches, I'd rather read something</div><div>complete and offer some more detailed feedback.</div><div><br></div><div>Bottom line: I see a slippery slope to tightly specified option that depend on kernel</div><div>versions, I see kernel options sprayed all over layers, etc, etc. Which is exactly</div><div>what we've been trying to avoid with the centralized kernel meta-data, and again,</div><div>there's a mechanism that I finished early this year to extend those options to any</div><div>kernel, enforce, warn, error, etc .. but now, I'll just toss it into the bin.</div></blockquote></div><br></span>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.</div></div></blockquote><div><br></div><div>You hit the nail on the head with that comment. There are some old bugzilla lurking around</div><div>about distro -> kernel options (aka kernel features) that I've suggested a similar concept</div><div>(or even machine features -> kernel).</div><div><br></div><div>IMHO some level of abstraction is needed for both, since otherwise we end up tightly</div><div>coupling recipes to a machine and kernel combination. </div><div><br></div><div>Someone can ask for a specific option all they like, but unless they know the details</div><div>of the kernel provider .. they are basically making a guess, and someone working with</div><div>many different types of recipes shouldn't have to know the details of every kernel tree</div><div>they are building. Sure it isn't widespread, or a lot of recipes, but again .. I see a slippery</div><div>slope.</div><div><br></div><div>In the case kernel doesn't have it they fail (or if they've specified something wrong), but</div><div>there are often substitutions that can be performed .. or optional features, etc. If there's some</div><div>level of abstraction, the kernel provider itself can turn on the right options, avoid common / minor</div><div>errors, make suggestions and ensure that the h/w (and kernel) actually has the capability.</div><div><br></div><div>The h/w actually having the capability is a significant issue for me as well, since asking for</div><div>something .. but not actually having the required h/w (or arch) support, and having no way</div><div>to abstractly figure out if something is supported .. means that even more knowledge of</div><div>the kernel and the machine starts slipping into recipes and ends up being spread all around</div><div>the layer stack.</div><div><br></div><div>Cheers,</div><div><br></div><div>Bruce</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br>-- <br><div>Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"</div>
</div></div>