[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