[llvmlinux] GSoC project ideas brainstorm
dl9pf at gmx.de
Tue Mar 19 20:01:33 UTC 2013
So let me summarize for now:
a) buildbot - complete rebuild with reporting, testsuite and more arch support
b) checker or static analysis of bc files (llvm/clang)
c) allyesconfig, tracing, validation suite (kernel)
If we agree on these, we can start to specify more closely.
Am Dienstag, 19. März 2013, 15:08:50 schrieb 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
> > 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.
If we think in the usual path ;) - yes, what you say is true for /arch/* .
This would be arch/cpu specific. Right. I wonder: What about the "rest" ;)
> 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.
jansimon.moeller at gmx.de
More information about the LLVMLinux