[llvmlinux] GSoC project ideas brainstorm

[Behan Webster]

On 03/19/13 10:29, Jan-Simon Möller wrote:
> Hi all!
> 
> Find my comments (after having slept over it ;) ) inline ... 
> 
> 
> Am Montag, 18. März 2013, 22:35:31 schrieb Tinti:
>> On Mon, Mar 18, 2013 at 2:20 PM, Jan-Simon Möller <dl9pf at gmx.de> wrote:
>>> Hi all!
>>>
>>> I'd like to start a brainstorm session on topics for GSoC.  The org
>>> application phase starts now and we'll apply.
>>>
>>> I'd propose to have 3-5 ideas available with different level of
>>> difficulty:
>>>
>>> easy:
>>> -  beaglebone target / $board target  -  including upstreaming and
>>> bugfixing
>>
>> Nice. Would be great specially for the new beaglebone.
> 
> I like the idea, but have doubts if it is enough work for the time of gsoc.
> We'd need to define tasks around that - e.g. debugging / remote debugging for 
> the target included.

I don't think it will be enough work for gsoc.

>>> -  work on infra (build infra or buildbot/jenkins?)
>>
>> Nice. But what exactly? Do we still need to use chroot? If we do, we could
>> work on fakeroot or the Yocto equivalent.
> No specific Idea right now - maybe Behan has more ideas here. I'd spend more 
> time on the actual linux/llvm side.

I think this would need to include a complete rebuild of the buildbot
with a lot more test cases, multiple architecture builds etc.

>> intermediate:
>>> -  Extend buildbot for x86
>>
>> Nice.
> 
> Maybe not enough content wise - combine with others.

This would probably be bundled with the previous.

>>> -  Add full ltp run with reporting
>>
>> Nice.
> 
> Can be a good topic if done with reporting.

Same again.

>>> -  Add reporting of error/warning/msg statistics (how many warnings of
>>> type X)
>>
>> Nice and very useful. Like a report at the end of the build: you have
>> warning X in the file.c:13 file3.c:19
>> Specially if this report could be stored by buildbot.
> 
> Exactly.  How many errors of type "foo" happened during that build and so on:
> Example:  http://clang.debian.net/  -> rebuild results

Same again.

>>> hard:
>>> - checker
>>
>> Do you mean the --emit-llvm and .bc? Yes, very good.
> 
> I mean the static analysis tool.

Yeah. Getting it working with the kernel, extending it for common kernel
issues.

> Otherwise another highly experimental idea : compile the kernel to .bc  and 
> link it with llvm-link and then produce target specific code from there.
> Completely different compilation workflow as we use it right now.

A sort of half compiled kernel? I'm really not sure how this would be
useful. The BC would still be intended for a particular arch (since you
can't compile for more than one arch at a time). For a purely analysis
point of view, separate bc files would likely be all that's necessary,
and somebody has done that already.

It would probably me more about a tool around the bc files to analyze
the kernel code in some way (hopefully in a bid to make llvm toolset
more attractive to the kernel community). However, I'm not sure any of
us are qualified to specify that kind of work and/or project.

>>> - llvm macros, llvm + realmode
>>
>> Nice. And how about llvm/clang self hosted (I mean try our builds from
>> llvm/clang built by llvm/clang)?
> 
> Yes, but thats not really hard - we're just lazy and don't want to spend the 
> time for the extra cycles.

I agree. Self hosted clang would be trivial, and largely a waste of time.

>>> - tracing, benchmarking, fix all errors in "make allyesconfig"
>>
>> Nice.

Some sort of complete validation suite on the complete kernel.

>> My suggestions:
>>
>> easy:
>> - analyze common errors in mainline kernel and check if some of them could
>> be upstream. Once I found an ; in a if statement.
> 
> This could be combined with the reporting above (how many warnings/errors of 
> type X) and so on.

This is probably merely part of the checker work above.

>> intermediate:
>> - run Android CTS test in Nexus 7 and check if it has some parts broken or
>> not. Try to fix the ones that are broken.
>> - llvm/clang self hosted.

Finishing/validating an LLVM Android build? Would be cool.

>> hard:
>> - llvm/clang for u-boot. Would be nice to see what we get from these
>> projects.
> 
> Same - core topic ?  It helps on the boards for sure - no question. But thats 
> step 2 for us right now.
> 
>> - llvm/clang for buildroot. Same as before.

Both of these are probably beyond the scope of our project, which is
using clang with the Linux kernel.

Ideally a gsoc candidate would help the LLVMLinux project increase the
adoption of clang with the kernel community, or help with work which
will support getting patches upstream.

Behan

-- 
Behan Webster
behanw at converseincode.com