[meta-freescale] [meta-fsl-arm][PATCH v3 3/6] linux-ls1: Add kernel recipes for Layerscape1 support

[Otavio Salvador]

On Wed, Sep 3, 2014 at 10:56 PM, zhenhua.luo at freescale.com
<zhenhua.luo at freescale.com> wrote:
>> -----Original Message-----
>> From: otavio.salvador at gmail.com [mailto:otavio.salvador at gmail.com] On
>> Behalf Of Otavio Salvador
>> Sent: Thursday, September 04, 2014 5:15 AM
>>
>> On Wed, Sep 3, 2014 at 5:42 AM, Zhenhua Luo <zhenhua.luo at freescale.com>
>> wrote:
>> > Signed-off-by: Zhenhua Luo <zhenhua.luo at freescale.com>
>> ...
>> > +# The ls1 defconfig is maintained in kernel source, copy it to #
>> > +${WORKDIR}/defconfig do_configure_prepend () {
>> > +    if [ ! -f ${WORKDIR}/defconfig ] && [ -f ${KERNEL_DEFCONFIG} ];
>> then
>> > +        cp ${KERNEL_DEFCONFIG} ${WORKDIR}/defconfig
>> > +    fi
>> > +}
>>
>> I understand why you does this however this makes very hard for users to
>> change the kernel config in a convenient way. Several users end doing
>> minor edits on the defconfig inside the layer for test purposes and I
>> think this is a good thing to have as we are very concerned with easy to
>> use.
> [Luo Zhenhua-B19537] I think above code is compatible with the defconfig usage in SRC_URI, defconfig defined in SRC_URI has the high priority. User can easily by add custom defconfig by append it in SRC_URI.
>         BTW, menuconfig should be the better way to do kernel configure, isn't it?

bitbake virtual/kernel -c menuconfig works in both ways. The kernel
class copies the WORKDIR/defconfig onto S/.config before calling the
menuconfig target.

>> Can you use the defconfig in SRC_URI and put it in the layer?
> [Luo Zhenhua-B19537] FSL maintains the kernel defconfig in kernel source for all QorIQ targets, so we want Yocto to get defconfig from kernel source directly to ensure the recent defconfig will be built.

I understand this. The i.MX team does the same.

The point is that is very easy for us (developers) to copy the
defconfig from the kernel source and include it on the metadata dir
when doing the recipe and keep this update when bumping the revision.
Doing that, we make user's life way easier to change setting (and even
propose changes).

Using the kernel defconfig from the Git makes harder to submit those
changes as user needs to use the Git checkout in tmp/work, prepare a
patch, put this in the recipe and use it.

So compare the two user workflows to enable CONFIG_FOO:

* bitbake virtual/kernel -c configure
* bitbake virtual/kernel -c devshell
* echo "CONFIG_FOO=y" >> .config
* make savedefconfig
* cp defconfig $KERNEL_DEFCONFIG
* git commit
* git format-patch
* copy the patch and edit the recipe to enable it

OR in case defconfig is on metadata:

* echo "CONFIG_FOO=y" >> recipes-kernel/linux/linux-foo/ls1/defconfig

What is more user friendly?

-- 
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