[llvmlinux] RFC: Unique handling of kernel-config files and working checkpoints

Sedat Dilek sedat.dilek at gmail.com
Tue Jul 16 10:07:33 UTC 2013


On Tue, Jul 16, 2013 at 11:38 AM, Jan-Simon Möller <dl9pf at gmx.de> wrote:
> Hi Sedat,
>
> find my comments below ...
>
> On Tuesday 16 July 2013 10:56:34 Sedat Dilek wrote:
>> Hi,
>>
>> Hereby, as promised some ideas for a "unique" handling of
>> kernel-config files and "working" checkpoints.
>>
>> [ IN GENERAL / LOCATION ]
>>
>> Any kernel-config files should be placed into a new
>> "targets/$arch/configs/" directory.
>> All kernel-config files should be physically accessible in the
>> llvmlinux-buildsystem!
>> With "any" or "all" I mean also the one for checkpoints.
>>
>> BAD EXAMPLE: nexus7
>>
>> Line #19: KERNEL_CFG              =
>> ${TARGETDIR}/src/android_kernel_nexus7/arch/arm/configs/cyanogenmod_grouper_
>> defconfig
>
> Actually this is an invalid example. This config is part of the android
> checkout and we don't even touch/modify it (just use).
>
> In general, I see no need to host 20 different config (like one for every
> $DISTRO, big, tiny). We can provide a working example matching the setup.
> Who should maintain this over time ? Everyone has his own tweaks or needs.
>
> That being said - the checkpointing can be improved, but that has serious
> implcations!
> Currently we do:
> - Use the provided hashes to reset llvm/clang/kernel/qemu/ltp back to that
>         state.
> - Now the fun starts: the patch-queue needs to match this versions. Right now
>         we also reset the build-system (and thus the patches) to the state in
>         time    where the checkpoint was taken. Works. But not optimal.
>
> SO to reach your goal, its better to improve this.
>
> Add the possibility to use (llvm/clang/kernel) patches from a checkpoint
> instead of the default directory. That gives us a "real" checkpoint.
>
> e.g.
> ls target/x86/checkpoints/<name>/:
>
>         ./llvmlinux.cfg         # make config output
>         ./patches/kernel        #(combined patches for this target's kernel at ref
>                                            $foo)
>         ./patches/llvm          #(needed for llvm at rev $foo)
>         ./patches/clang         #(needed for clang at rev $foo)
>         ./kernel.config         # matching kernel .config
>
> You get the idea.  Mix that with your naming scheme below as you wish.
>
> The point is: we need a matching set of patches (aka "back-in-time") available
> w/o changing the build-systems git revision back.
>
> A make target "make checkpoint NAME=foo" could automate copying things around.
>
> @Behan might have some hints here.
>

Hi Jan,

what about the idea to split into llvmlinux ("stable" development) and
llvmlinux-next ("unstable" development)?

I am aware of the redundancy, especially of patches.

But I am keen on the latest stable version of toolchain and Linux-kernel.
So, why not keep checkpoints only for the latest stable (Linux-kernel) version?

What is missing towards patches: A history...
All irrelevant (dropped) patches should go to an (existing) archive
together with a changelog/timestamp and the information which
upstream-patch (commit-id and subject-line) replaced it. The
git-revision of llvmlinux would not hurt to (-> idea of checkpoints).

EXAMPLE:

ChangeLog:
2013-07-13: x86_64: Dropped 0041 patch, fixed upstream by commit ...
("subject/name of patch")

I cannot say if symlinking can reduce the patch-handling and the data.
I know this is a difficult story.

But as you have seen, people ask (demand?) for stable settings/configs.
It is like in real-life:
Live "risky" VS. try to establish a "stable"and "realisable"
environment where you feel good.

For lllvmlinux you do things once (checkpoints).
Adaptations will only be needed in llvmlinux-next.

Look at the Linux-kernel development process:
Linux-stable <- Linux-upstream <- Linux-next
...or look at the Debian-distro:
The development is realized in four stages: stable <- testing <-
unstable <- experimental

Simply focussing on GIT HEAD can NOT be successful in my eyes.

Just some ideas to make developers and users happy.

- Sedat -

> --JS
>
>
>> [ NAMING SCHEME ]
>>
>> Kernel-config files of checkpoints should be named accordingly!
>>
>> EXAMPLE:
>>
>> Name of checkpoint-Makefile: "targets/$arch/checkpoints/chp1.mk"
>> Name of kernel-config file:  "targets/$arch/configs/config_$arch_chp1"
>>
>> All checkpoint(s)-dir should have the same dirname!
>>
>> EXAMPLES:
>>
>> x86_64: dirname "CHECKPOINTS" (upper-case and plural)
>> rpi:    dirname "checkpoint" (lower-case and singular)
>> nexus7: dirname "checkpoint" (lower-case and singular)
>>
>> If you ask me, I vote for "checkpoints" (plural and lower-case).
>>
>> Regards,
>> - Sedat -
>>
>> [1]
>> http://git.linuxfoundation.org/?p=llvmlinux.git;a=blob;f=targets/nexus7/che
>> ckpoint/ckp2.mk#l19 [2]
>> http://git.linuxfoundation.org/?p=llvmlinux.git;a=tree;f=targets/x86_64/CHE
>> CKPOINTS [3]
>> http://git.linuxfoundation.org/?p=llvmlinux.git;a=tree;f=targets/rpi/checkp
>> oint [4]
>> http://git.linuxfoundation.org/?p=llvmlinux.git;a=tree;f=targets/nexus7/che
>> ckpoint _______________________________________________
>> LLVMLinux mailing list
>> LLVMLinux at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux


More information about the LLVMLinux mailing list