[meta-freescale] [meta-fsl-arm][PATCH] linux-ls1: add support for kernel configuration fragments
Otavio Salvador
otavio at ossystems.com.br
Sat Oct 18 11:22:31 PDT 2014
Hello Bruce,
On Fri, Oct 17, 2014 at 3:23 PM, Bruce Ashfield
<bruce.ashfield at gmail.com> wrote:
> On Thu, Oct 16, 2014 at 10:21 PM, Zongchun.Yu at freescale.com
> <Zongchun.Yu at freescale.com> wrote:
>> Which part are you referencing here ? The LOCALVERSION changes ?
>> [Zongchun] I have separated the codes from this patch. these codes can also add git revision to local version. Please refer to the following:
>> +kernel_conf_variable() {
>> + if test "$2" = "n"
>> + then
>> + echo "# CONFIG_$1 is not set" >> ${B}/.config
>> + else
>> + echo "CONFIG_$1=$2" >> ${B}/.config
>> + fi
>> +}
>> +
>> +do_configure_prepend() {
>> + kernel_conf_variable LOCALVERSION "\"${LOCALVERSION}\""
>> + kernel_conf_variable LOCALVERSION_AUTO y
>> +
>> + if [ "${SCMVERSION}" = "y" ]; then
>> + # Add GIT revision to the local version
>> + cd source
>> + head=`git rev-parse --verify --short HEAD 2> /dev/null`
>> + cd -
>> + printf "%s%s" +g $head > ${S}/.scmversion
>> + fi
>> +}
>>
>> May I know your comments? Thanks.
>
> Setting and manipulating raw CONFIG variables from within recipes is something
> that we've been trying to avoid via the configuration fragments.
I am not aware of other uses of kernel_conf_variable in the recipes;
we could even move it to an internal code of the SCMVERSION handling.
> Getting the localversion
> right makes sense, but not at the expense of spreading configuration
> changes into
> a wider set of inputs (recipes, variables, fragments, python routines, etc).
That's why I think we ought to move this to kernel.bbclass and avoid
redoing it over and over again. Another possibility is to have a
kernel-scmversion class that adds it but I think this is overkill.
> We already have a hard time managing configuration consistently and if
> CONFIG* variables need to be hunted and found, along with fragments and other
> custom routines .. then the entire system becomes harder to maintain
> (in particular
> when delivered BSPs are layered and modified).
>
> I'm definitely interested in solving configuration gaps, hopefully
> without needing to
> introduce more ways to configure the kernel. There are some existing bugzilla
> entries on this, and the priority is being bumped for Yocto 1.8.
Could you elaborate on the plans for it? Would you support a patch
including the LOCALVERSION handling?
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
More information about the meta-freescale
mailing list