[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