[llvmlinux] GSoC project ideas brainstorm

[Jan-Simon Möller]

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. 


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

> 
> > -  ...
> 
> intermediate:
> > -  Extend buildbot for x86
> 
> Nice.

Maybe not enough content wise - combine with others.

> > -  Add full ltp run with reporting
> 
> Nice.

Can be a good topic if done with reporting.

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


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

I mean the static analysis tool.  

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.

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

> > - tracing, benchmarking, fix all errors in "make allyesconfig"
> 
> Nice.
> 
> > - ..
> 
> 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.

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

Imho could be closer to our core topics - what do you think ?

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

Dito.

Best,

Dipl.-Ing.
Jan-Simon Möller

jansimon.moeller at gmx.de