On Tue, May 3, 2016 at 11:13 AM, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
> On Tue, 3 May 2016, Bruce Ashfield wrote: > > > If you are not supplying a defconfig, and are inheriting the > > standard kernel options, then yes, you'd be getting those fragments > > as well. > > ah, this actually leads me into my next question -- what is magic > about a "defconfig" file that changes the normal processing?\ > It's the existing kernel.bbclass mechanism, and a well known convention used in the kernel. So it is used to trigger the core kernel configuration, and when I was extending things for kernel fragments it was similarly used as a sentinel value. > > in the YP kernel dev manual, section 2.2.3, one reads: > > "If you have a complete, working Linux kernel .config file you want to > use for the configuration, as before, copy that file to the > appropriate ${PN} directory in your layer's recipes-kernel/linux > directory, and rename the copied file to "defconfig". Then, add the > following lines to the linux-yocto .bbappend file in your layer: > > FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" > SRC_URI += "file://defconfig" > > so the idea here is that a "defconfig" file is, in some sense, a > "complete, working" config file that requires no extra processing, is > that correct? does that mean that if you explicitly use a SRC_URI > "defconfig" reference, all that extra normal processing won't be done? > Nope. Everything is still processed, the kernel version you are using, patches, etc, all make a difference to what ends up in the .config. The phrasing there is to point out that it is what the mainline kernel considers a defconfig, and it is typically a complete configuration of the kernel (that is expected to boot your target). > > also, that same section in the YP manual is slightly confusing -- if > your SRC_URI refers to a defconfig file *and* some .cfg fragment > files, is it necessarily true that the defconfig file is consulted > first (no matter where it shows up in SRC_URI), after which all .cfg > files are applied on top of that in order? it's not entirely clear > from the manual if that's what happens. > Yep. If you mix the two techniques, the defconfig is first (and taken as the settings), and then fragments are applied on top. Note: There are some changes in defconfig that are related to features I'm doing for the fall 2.2 release, but nothing that changes the basic processing (so compatibility is maintained). Bruce > > predictably, a couple more kernel config questions coming ... > > rday > > -- > > ======================================================================== > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > ======================================================================== > > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core