New Development In previous hack weeks, the first few days ended up being wasted on just getting it working. I'm pleased to share that the code quality has improved dramatically since the last hack week and there are now extensive test cases for both unit testing and testing against real vmcores, and we'll use both mypy and pylint (if installed) to perform static analysis. Packages for those are available in openSUSE or as part of the crash-python OBS repo for SLE15. It has been tested with kernels from 3.0 to 5.1.

Talking to people, getting the information about what had happened in the SUSE history, bringing all together to kind of a chronicle. Let's give it a try :-)

Implement improved ftrace infrastructure for PPC64LE (goal 1), s390x (goal 2), ARM64 (goal 3) that is able to support kGraft and doesn't have a performance impact. PPC64LE has an experimental (untested) patch by Dinar Valeev already, s390x works, but has a 10% performance impact on the system, ARM64 is entirely untouched.

Plan

RandR is X11 extension for configuring monitors and since version 1.4 also secondary GPUs. These secondary GPUs can either provide additional monitors to output to or can render individual applications instead of the main GPU. (Or even both at once.) Once a secondary GPU is configured to do render offloading, applications can be started with DRI_PRIME=<id> environment variable to actually render on it instead of the main one. There are also USB GPUs (dummy framebuffers) that can be hot-plugged.

I have a Canon PowerShot S120, which allows for browsing / copying photos over WiFi. There are apps for Android, iOS, and Windows to do that. The protocol uses upnp to discover the camera and the smartphone/computer and them some HTTP-based protocol. I have some code using libupnp for the discovery and a perl script that is capable of transfering one file, but it's far from complete. Plus, I need to refresh my memory, because the last commit is from January :-(. Now, there seems to be some support for such cameras in gphoto already. So the plan is to dive into gphoto and use what I learned about the protocol to fix the gphoto support. If you own some other WiFi-enabled Canon camera supported by the CameraWindow software, let me know.

Having gotten access to some SMR prototypes it should be possible to tweak btrfs to run natively on those devices. Using SSD mode helps a lot, but there is still some work to be done. So this will be a good chance to learn something about the inner details of btrfs and see if I can get it to run on SMR drives.

This is the tool I've been working on since HW11 and it needs more work. Actually, there's always something which could be done on it. It is basically an x86 instruction decoder with special emphasis on the kernel and decoding interesting pieces of it in order to help in the development of low-level patching techniques, among others. git repo: https://gitlab.suse.de/bp/x86d

The idea is to have an internal web page that mainly presents new SUSE employees or the ones you might not know yet. Other topics can be covered like reports about hack week projects or other interesting stuff apart from the daily work we all do. As a start there would be a questionnaire which results are posted on a web page.

Project Description

If nothing is changed, no Hackweek T-Shirt awaits us. So, taking the initiative, I am searching for other creative minds to collaborate with.

Currently GCC relies only on the most generic alias analysis when attempting to track data in aggregates in interprocedural (IPA) optimizations. In the course of this project I plan to revive patches for using simple escape analysis to track all data which do not have their address escaped and use that information to track constants within them, analyze the impact on a number of benchmarks and submit them to GCC trunk.

It is well-known that two git commits within a single repo can be independent from each other, by changing separate files to each other, or changing separate parts of the same file(s). Conversely when a commit changes a line, it is "dependent" on not only the commit which last changed that line, but also any commits which were responsible for providing the surrounding lines of context, because without those previous versions of the line and its context, the commit's diff would not cleanly apply. As with most dependency relationships, these form a directed acyclic graph. Sometimes it is useful to understand the nature of parts of this graph; for example when porting a commit "A" between git branches via git cherry-pick, it can be useful to programmatically determine in advance the minimum number of other dependent commits which would also need to be cherry-picked to provide the context for commit "A" to cleanly apply.

Look at static code analysis and code coverage for a C++ project, in this case libstorage-bgl-eval. This could include:

Learn Coccinelle ,we need automatic kernel backporting with Coccinelle.

gdb-kdump (and libkdumpfile) needs a plenty of improvements and tasks to be done. For HackWeek 13, Vlastimil chose to work on SLAB memory support, Petr, amongst other things, reorganized the libkdumpfile code and alnovak begun with libkdumpfile's ppc64 support. Our status in 4/5 of HackWeek 13:

SLAB

During hack week I will carry on the research I started to write my thesis. The work is called "Turbulence Driven Clustering in Nematic Active Particles" and will (hopefully) make it into a Physical Review Letters paper.

Packman reduction

This is about writing a tool to find differences in assembly files generated by gcc. The goal is to find the symbols in a program that have changed by a source code patch. This information can then be used to create and/or verify kGraft patches.

At SUSE LabsConf 2015 we decided to run some sort of automated tests on the SLE and openSUSE kernels after each push to kerncvs.suse.de In order to make this work the kernel has to be build, a initrd and a rootfs image has to be generated for use with qemu, it has to be booted and tests have to be run.

"Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open."[1]

Project Description

Different people use different ad-hoc tools to debug Linux kernel MM (memory management) related issues. I have couple of those myself. They fall into two main categories. One set for proper data collection and the other for some high level analysis. Our customers would benefit from the former and we (L3 labs from the later). Having them in a single package sounds quite reasonable to me.

Project Description

When we experience a early boot crash, we are not able to analyze the kernel dump, as user-space wasn't able to load the crash system. The idea is to make the crash system compiled into the host kernel (think of initramfs) so that we can create a kernel dump really early in the boot process.