Hardware and software will never stop evolving, yet many still choose to push out static documentation without the resources to maintain, edit, and push new versions. When these documents inevitably become obsolete, they float around the internet and offer little more than confusion. In many cases you will find yourself with more questions than answers by the end of an instruction set, with no one available to help. 96Boards aims to end outdated documentation by implementing a dynamic approach which utilizes member and community resources, paired with on point maintenance and diligent review from the 96Boards team and Linaro. Doing this, we can provide up-to-date, straightforward, and accurate documentation without the need to share documents, convert formats, or refer to releases/versions when wondering if the document is going to work.
Deep dive into LLVM internals, middle/back-ends, libraries, sanitizers, linker, debugger and overall compilation process. The focus is to show how LLVM works under the hood, which is useful for GCC compiler engineers getting into LLVM development, as well as for other engineers to learn more about parts of the toolchain they’re not familiar with. This presentation also touches on frequent LLVM-specific errors, so GCC users may find useful, if they’re moving to LLVM.
Since the presentation back in 2015 (SFO15), there has been functionality added, like RPMB and there has also been some changes in general to the secure storage code. This presentation will summarize what has been happening and will also talk about what’s left to do.
This presentation will discuss issues and common mistakes when migrating a project from one toolchain to another. The main focus will be on issues coming from switching from GCC to Clang, but we will also touch on differences in libraries, assemblers and linkers. The presentation will also make fun of bad practices and quick hacks that project porters sometimes use to “make-it-compile”.
**Title: Community 3.0**
The history of open source is littered with incredible communities: thousands of people connected around the world building new technology and innovating. We can do better though. We are a facing a new era of challenges and opportunities for collaboration at a global level. In this presentation from Jono Bacon, he will explain how we can build a new generation of communities that are more efficient and more productive than ever before.
The keynote will cover how community has evolved over the years, the structure of building powerful technical and open source communities, building workflow and on-ramps, building growth, and the balance between company and community relations. All of this will be wrapped up in his trademark loose and entertaining style.
Previously Director of Community at Canonical, GitHub, XPRIZE, and OpenAdvantage. Advisor to organizations includingAlienVault, Open Networking Foundation, Open Cloud Consortium, Mycroft, and others. Wrote the critically acclaimed The Art of Community, founder of the Community Leadership Summit and global CLSx events, and prominent leader in community leadership, strategy, and execution featured on CNN, .NET, Forbes, Linux Format, and elsewhere. Founder of Jono Bacon Consulting that provides community strategy, management, and workflow consultancy for Fortune 500 companies, startups, and government across the globe.
KVM/ARM has grown up. While the initial implementation of virtualization support for ARM processors in Linux was a quality upstream software project, there were initial design decisions simply not suitable for a long-term maintained hypervisor code base. For example, the way KVM/ARM utilized the hardware support for virtualization, was by running a 'switching' layer of code in EL2, purely written in assembly. This was a reasonable design decision in the initial implementation, as the switching layer only had to do one thing: Switch between a VM and the host. But as we began to optimize the implementation, add support for ARMv8.1 and VHE, and added features such as debugging support, we had to move to a more integrated approach, writing the switching logic in C code as well. As another example, the support for virtual interrupts, famously known as the VGIC, was designed with a focus on optimizing MMIO operations. As it turns out, MMIO operations is a less important and infrequent operation on the GIC, and the design had some serious negative consequences for supporting other state transitions for virtual interrupts and had negative performance implications. Therefore, we completely redesigned the VGIC support, and implemented the whole thing from scratch as a team effort, with a very promising result, upstream since Linux v4.7. In this talk we will cover the evolution of this software project and give an overview of the state of the project as it is today.