<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 9, 2016 at 4:45 PM, 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">Hi Bruce,<br>
<span class=""><br>
On Mon, 09 May 2016 08:05:06 Bruce Ashfield wrote:<br>
> On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <<br>
> <a href="mailto:paul.eggleton@linux.intel.com">paul.eggleton@linux.intel.com</a>> wrote:<br>
> > 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>
><br>
> So what's the overall design for this ? Is it documented anywhere ? This is<br>
> something that we talked about a couple of years and I have reservations and<br>
> objections to the current implementation.<br>
><br>
> .. but since I can only see bits and chunks of patches, I'd rather read<br>
> something complete and offer some more detailed feedback.<br>
><br>
> Bottom line: I see a slippery slope to tightly specified option that depend<br>
> on kernel versions, I see kernel options sprayed all over layers, etc, etc.<br>
> Which is exactly what we've been trying to avoid with the centralized kernel<br>
> meta-data, and again, there's a mechanism that I finished early this year to<br>
> extend those options to any kernel, enforce, warn, error, etc .. but now,<br>
> I'll just toss it into the bin.<br>
<br>
</span>There's no design written out beyond what you see in the associated bug:<br>
<br>
<a href="https://bugzilla.yoctoproject.org/show_bug.cgi?id=5574" rel="noreferrer" target="_blank">https://bugzilla.yoctoproject.org/show_bug.cgi?id=5574</a><br>
<br>
The situation I am trying to avoid is the exact one mentioned by a commenter<br>
on that bug - which is that if I build my rootfs in a particular way, and<br>
couple it with a particular kernel configuration, I want the build system to<br>
tell me if those are going to be incompatible. The current situation where the<br>
you don't find out until the system doesn't boot (and you may not get any<br>
meaningful error message at that point anyway) isn't great.<br>
<br>
You mention hardware in your reply to Chris, but this mostly isn't about<br>
hardware - it's about dependencies on software features of the kernel from<br></blockquote><div><br></div><div>I only brought up h/w to point out the slippery slope, and that if you are going to</div><div>solve one class of options, eventually it will lead to someone asking for others</div><div>and then the ability to set them. We then have a tight binding and distributed</div><div>knowledge of the kernel specifics.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
userspace. I'm perfectly happy if we go for alternative solution, but to my<br>
mind whatever solution we come up with needs to be something whereby if you<br>
enable something in userspace that the kernel as currently configured isn't<br>
going to be able to support, you at least get a warning at build time.<br></blockquote><div><br></div><div>What you describe is almost exactly what KERNEL_FEATURES + the existing Kconfig</div><div>audit does. That mechanism does the audit for software and h/w features via a level</div><div>of abstraction (the name of the feature, versus the kernel options themselves).</div><div><br></div><div>I'm about 75% of the way to extended that to any kernel (not just linux-yocto) and</div><div>exposing the "required" and "optional" kconfig support (that has been around for</div><div>about 1.5 years .. just no one has asked for it :D</div><div><br></div><div>That's why I'm trying to understand what exactly is missing and is being solved</div><div>here, so I can decide whether to drop my changes or not.</div><div><br></div><div>Bruce</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Paul<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<br>
Paul Eggleton<br>
Intel Open Source Technology Centre<br>
</font></span></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>