[llvmlinux] Quick build against stable versions of toolchain (llvm and clang) and Linux-kernel?

Tinti viniciustinti at gmail.com
Fri Jan 18 01:35:33 UTC 2013


Hi Sedat,

About stable versions please check my branch. I have just uploaded the
documentation about it (Documentation/settings_file.txt) and an example in
rpi target. I think it fits for your purposes.
I have not applied on master because I would like to have some reviews and
feedbacks. Is anything else that you would like to add?

Best regards,
Tinti

What is {the | your | a good} base for the Linux-kernel (speaking of
> x86_64)?
> v3.7.y (latest stable version)?
>
The LLVMLinux project works from the HEAD of LLVM and the Linux project.
Since the goal is to upstream patches to both projects, we really have to
work from HEAD.

As far as saving checkpoints that work with a particular version of a
kernel, somebody merely needs to create a settings file which details the
versions of all SW involved. The settings file is described in
Documentation/settings_file.txt

Tinti is using this to create a checkpoint for the rpi community so that
people can play with a stable kernel there for instance. You are welcome to
do the same for x86_64.



On Thu, Jan 17, 2013 at 2:53 PM, Behan Webster <behanw at converseincode.com>wrote:

> On 13-01-17 09:11 AM, Sedat Dilek wrote:
>
>> Hi,
>>
>> first of all I wish all people from the LLVMLinux project a happy new
>> year!
>>
> Same to you! :)
>
>
>  After a case of death in my family I dropped all my OSS activities for a
>> while.
>>
> I'm very sorry to hear that.
>
>
>  The last weeks I started to build again mainline and Linux-Next kernels.
>> ...and playing with Linux Test Project (LTP).
>> I would like also to test a llvmlinux-compiled Linux-kernel with LTP!
>>
> We are already running LTP with a clang compiled kernel, but currently
> only for the vexpress (ARM based) kernel. It's just a matter of somebody
> porting the code. I too would like to see an automated x86 LTP test run.
>
>
>  Today, I remembered the $JOBS variable
>>
> "make help" has details about a lot of things, including the $JOBS
> variable. The default value of JOBS likely will be close to optimum. On my
> machine (at least) if I ingrease JOBS much higher than the calculated
> default, it actually slows down the compile.
>
>
>  What is {the | your | a good} base for the Linux-kernel (speaking of
>> x86_64)?
>> v3.7.y (latest stable version)?
>>
> The LLVMLinux project works from the HEAD of LLVM and the Linux project.
> Since the goal is to upstream patches to both projects, we really have to
> work from HEAD.
>
> As far as saving checkpoints that work with a particular version of a
> kernel, somebody merely needs to create a settings file which details the
> versions of all SW involved. The settings file is described in
> Documentation/settings_file.**txt
>
> Tinti is using this to create a checkpoint for the rpi community so that
> people can play with a stable kernel there for instance. You are welcome to
> do the same for x86_64.
>
>
>  $ grep "Kernel Configuration" -nr ./
>> ./targets/x86_64/config_x86_**64:3:# Linux/x86_64 3.7.0 Kernel
>> Configuration
>> ./targets/x86_64/config_x86_**64_default:3:# Linux/x86_64 3.7.0-rc5
>> Kernel Configuration
>> ./targets/i586/config_i586:3:# Linux/x86_64 3.7.0 Kernel Configuration
>>
> That's merely the version of the kernel that was being used when that
> config file was last updated. It doesn't indicate a stable version of the
> kernel source.
>
>
>  Is the listed kernel-config a good base?
>>
> It is the one we are currently testing with. This file is intended to
> create a bootable kernel on an average x86_64 computer.
>
>
>  Same question to llvm and clang.
>> v3.2 (latest stable version)?
>>
> Again, we don't use stable versions of the toolchain. We use HEAD. Until
> our patches are in we have to keep developing and testing with the
> latest/greatest code.
>
>
>  Personally, I wanted to test against ***stable*** versions of all 3
>> components.
>>
> Great! That would be very helpful.
>
>
>  Some patches are not listed in the appropriate series files (so-to-say
>> UNUSED).
>>
> The existence of a patch file doesn't mean it's actually being used. The
> series file lists which patches are currently in use.
>
> Patches which aren't in a series file usually are left in place until
> we're sure we don't need them anymore (or at all).
>
>
>  I am still against all this uncommon naming of patches (speaking
>> mostly of the ones for the Linux-kernel).
>>
> In this case many of the patch names for x86_64 have been created from the
> commit comments by "git format-patch".
>
> I would encourage you to work within our build framework if you can. If we
> all work on the same code base, with the same test framework, we can much
> more easily share work and accelerate our efforts.
>
> Thanks!
>
> Behan
>
> --
> Behan Webster
> behanw at converseincode.com
>
>
> ______________________________**_________________
> LLVMLinux mailing list
> LLVMLinux at lists.**linuxfoundation.org<LLVMLinux at lists.linuxfoundation.org>
> https://lists.linuxfoundation.**org/mailman/listinfo/llvmlinux<https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux>
>



-- 
Vinicius Tinti
mail => {viniciustinti at gmail.com, tinti at comp.eng.br}
skype => {viniciustinti}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20130117/47d56905/attachment.html>


More information about the LLVMLinux mailing list