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

Jan-Simon Möller dl9pf at gmx.de
Tue Jul 16 09:38:29 UTC 2013


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.

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