Language Selection

English French German Italian Portuguese Spanish

today's howtos

More in Tux Machines

GNOME Development: Technical Reports From Federico Mena-Quintero and Jussi Pakkanen

  • Refactoring the Length type

    Over a couple of years, librsvg's type that represents CSS lengths went from a C representation along the lines of "all data in the world is an int", to a Rust representation that uses some interesting type trickery: C struct with char for units. C struct with a LengthUnits enum. C struct without an embodied direction; each place that needs to normalize needs to get the orientation right. C struct with a built-in direction as an extra field, done at initialization time. Same struct but in Rust. An ugly but workable Parse trait so that the direction can be set at parse/initialization time. Three newtypes LengthHorizontal, LengthVertical, LengthBoth with a common core. A cleaned-up Parse trait. A macro to generate those newtypes. Replace the LengthDir enum with an Orientation trait, and three zero-sized types Horizontal/Vertical/Both that implement the trait. Replace most of the macro with a helper trait LengthTrait that has an Orientation associated type. Replace the helper trait with a single Length<T: Orientation> type, which puts the orientation as a generic parameter. The macro disappears and there is a single implementation for everything. Refactoring never ends!

  • Some intricacies of ABI stability

    As far as I know, there is no known real-world solution to this problem that would scale to a full operating system (i.e. all of Debian, FreeBSD or the like). If there are any university professors reading this needing problems for your grad students, this could be one of them. The problem itself is fairly simple to formulate: make it possible to run two different, ABI incompatible C++ standard libraries within one process. The solution will probably require changes in the compiler, linker and runtime loader. For example, you might extend symbol resolution rules so that they are not global, but instead symbols from, say library bar would first be looked up in its direct descendents (in this case only abi2) and only after that in other parts of the tree. To get you started, here is one potential solution I came up with while writing this post. I have no idea if it actually works, but I could not come up with an obvious thing that would break. I sadly don't have the time or know-how to implement this, but hopefully someone else has.

Graphics and Games: Intel, Vulkan, Trine and Google Stadia

  • Intel's Graphics Driver DoS Fix Last Week Has Hurt Power Consumption

    While the patches overnight about "substantial" improvement in power usage for Intel graphics on Linux were exciting on first look, it's less so now as it turns out last week's graphics driver security fixes is what regressed the Intel graphics power-savings. During last Tuesday's round of Intel security disclosures where there was a fix for denial of service in the Intel graphics driver, it turns out that the CVE-2019-0154 fix is what regressed power usage. The potential Denial of Service vulnerability was about unprivileged users being able to cause a DoS by reading select memory regions when the graphics hardware is in certain low-power states.

  • vkBasalt 0.2 Released With SMAA, Other Vulkan Post Processing Layer Enhancements

    The open-source vkBasalt project was started as a layer implementing Contrast Adaptive Sharpening (akin to Radeon Image Sharpening) for any Vulkan-using GPU/driver/software. The vkBasalt project then picked up FXAA support for this Vulkan post-processing layer while now a new release is out with more functionality added. The vkBasalt 0.2 release is out today and adds support for enhanced sub-pixel morphological anti-aliasing (SMAA) for higher-quality anti-aliasing than FXAA. SMAA is an image-based implementation of MLAA. This release also allows for multiple visual effects to be activated at once where as previously only any one of these image enhancing features could be active at a time.

  • Flax Engine Ported To Linux + Vulkan Rendering Support

    Flax Engine is the latest game engine seeing native Linux support and in the process the renderer also picked up Vulkan support. Flax Engine is a lesser known game engine that now works on Linux alongside Windows and Xbox One. After two years in development, the open beta release of Flax is expected soon.

  • The sad case of Trine on Mesa and Linux in 2019

    A year or so back I was planning on writing a congratulatory article to show my appreciation to Dave Airlie for fixing a long standing bug in Mesa that prevented users of older AMD Radeon HD cards from enjoying Trine Enchanted Edition on the free graphics stack. Bug 91808 resulted in a variety of graphical artifacts which, while not interfering with the gameplay, still put me off using that version of Trine. After several years and a great deal of evident frustration on his part, Airlie was able to track down the root of the problem and at long last was able to push a fix to master in May 2018. Airlie and developers like him are often the unsung heroes of FOSS development, and I wanted to give him a well deserved public pat on the back for his effort in fixing a bug which would only have affected such a small number of people. Unfortunately my research into this led me down an entirely different rabbit hole when I discovered the report for Bug 66067. A much more subtle misrendering of the game's colours and lighting, this bug is present in both Trine 2 and Trine Enchanted Edition and affects all Mesa users. Unlike the previous instance where it was an issue in the drivers that was the culprit, this issue is present in the game binaries themselves.

  • Google Stadia is out now for early adopters, well a few anyway

    Today, the Google Stadia streaming service officially launched for those who picked up the Founder or Premier Edition. Well, sort of anyway. Some people have it, a lot of people don't, we certainly don't and it appears the team at Stadia give different answers to different people on when you will actually be able to access it. I've also seen plenty of people whose orders have been cancelled without warning or explanation. Even worse still, some people have been sent their hardware without an access code. Google have, so far, done a terrible job at communicating on Stadia and so the initial launch doesn't seem to have gone down well at all.

SystemTap 4.2 release

The SystemTap team announces release 4.2!

support for generating backtraces of different contexts; improved backtrace
tapset to include file names and line numbers; eBPF support extensions
including raw tracepoint access, prometheus exporter, procfs probes and
improved looping structures

= Where to get it

  https://sourceware.org/systemtap/ - Project Page
  https://sourceware.org/systemtap/ftp/releases/
  https://koji.fedoraproject.org/koji/packageinfo?packageID...
  git tag release-4.2 (commit 044a0640985ef0)

  There have been over 110 commits since the last release.
  There have been over 25 bugs fixed / features added since the last
release.

= SystemTap frontend (stap) changes

- When the -v option is set along with -L option, the output includes
  duplicate probe points which are distinguished by their PC address.

- Now it is possible to issue a backtrace using user specified pc, sp,
  and fp which can be used to generate backtraces of different contexts.
  This was introduced to get backtraces of user code from within the go
  runtime but it can also be used to do things like generating backtraces
  of user code from within signal handlers.

- The automatic printing implementation now differentiates between
  pointer and integer types, which are printed as hex or decimal
  respectively.

= SystemTap backend changes

- Initial support for multi-dimensional supports has been added to
  the stapbpf backend. Note that these arrays cannot be iterated upon
  with a foreach loop.

- The stapbpf backend now supports sorting by value in foreach loops.

- The stapbpf backend now supports the concatenation operator for
  userspace probes.

- The stapbpf backend now supports the target() function and -x option.

- The gettimeofday_* functions are now provided for the stapbpf backend.

- The stapbpf backend now supports order parameterization for begin
  and end probes.

- The stapbpf backend now supports stap-exporter extensions.

- The stapbpf backend now supports procfs probes. The implementation
  uses FIFO special files in /var/tmp/systemtap-$EFFUSER/MODNAME instead
  of the proc filesystem files.

- The eBPF backend now uses bpf raw tracepoints for kernel.trace("*")
  probes.  These have target variable arguments that match the
  arguments available for the traditional linux kernel modules
  tracepoints.  Support for the older bpf tracepoint arguments can be
  forced with a --compatible=4.1 option on the command line.

- The compiler optimizes out probes with empty handlers. Previously,
  warnings were issued but, the probe was not internally removed. For
  example, this script now outputs a warning and an error as the only
  probe handler is empty:

      probe begin {}

  Additionally, probe handlers that evaluate to empty are also removed.
  For example, in this script, the begin probe is elided as $foo does
  not exist, however, an error won't be outputted because atleast one
  probe with a non-empty handler exists (probe begin):

      probe begin {
          print("Protected from elision")
      }

      probe end {
          if (@defined($foo)) { print("Evaluates to empty handler") }
      }

- The sys/sdt.h file changes the way i386 registers operands are
  sometimes named, due to an ambiguity.  A comment block explains.

= SystemTap tapset changes

- New backtracing functions print_[u]backtrace_fileline() have been added
  to the tapset. These functions behave similarly to print_[u]backtrace(),
  the only difference being that file names and line numbers are added
  to the backtrace.

= SystemTap sample scripts

All 180+ examples can be found at https://sourceware.org/systemtap/examples/
.

- Several sample scripts have been enabled to run on the stapbpf backend:

apps/libguestfs_log.stp
network/sk_stream_wait_memory.stp
memory/mmfilepage.meta
memory/mmwriteback.meta
general/ansi_colors.meta

- New stap-exporter sample script for the stapbpf backend:

syscallsrw.stp    Tallies the read and write syscalls.

= Examples of tested kernel versions

2.6.32 (RHEL6 x86_64)
4.15.0 (Ubuntu 18.04 x86_64)
4.18.0 (RHEL8 x86_64, aarch64, ppc64le, s390x)
5.0.7  (Fedora 29 x86_64)
5.3.8  (Fedora 30 i686)
5.3.9  (Fedora 31 x86_64)
5.4.0-rc  (Fedora 32 x86_64)

= Known issues with this release

- The array dump macros which are used with prometheus probes do not
entirely
  work with stapbpf as the macros use foreach loops which cannot be used
with
  multi-dimensional arrays yet.

- The user_string() function in the BPF tapsets uses the BPF
probe_read_str()
  helper, which only works correctly when there is no address translation
  between user and kernel address spaces. It has been restricted to x86_64
  only until the BPF infrastructure provides separate helpers for reading
user
  and kernel data.

= Coming soon

- More stapbpf functionality including full statistics aggregate support
and
  try-catch blocks.

= Contributors for this release

*Carlos O'Donell, Frank Ch. Eigler, Jafeer Uddin,
*Richard Purdie, Ross Burton, *Sagar Patel, Serhei Makarov
Stan Cox, *Wenzong Fan, William Cohen

Special thanks to new contributors, marked with '*' above.

Special thanks to Sagar for assembling these notes.

= Bugs fixed for this release &tl;https://sourceware.org/PR#####>

9922    need to configure with --disable-pie on ubuntu
25174   string auto-concat doesn't work in @var / @cast module parameter
25169   strcpy overlap between transport arg and string on-stack
25133   stapbpf foreach loop crashing
24953   foreach (v = v1,v2) syntax not behaving correctly in stapbpf
24812   stapbpf: support order-parametrized begin/end probes
25113   Explanation and "code" mismatch in section ⁠2.3.1.2. File Flight
Recorder
25107   need -L variant that doesn't merge duplicate probe points
23285   stapbpf procfs probes
24946   printing hex sequences causes crash
24947   valid hex and octal sequences not checked for
24926   non-ascii characters not printing on stapbpf
24934   stapbpf stack-smash on EXIT message processing
23879   print_ubacktrace can not print function name
24875   VMA tracker is broken on Fedora 29
24904   stack_trace struct undefined on kernel 5.2
23858   sorted iteration on bpf arrays can't sort values
24885   add test_{,install}check_dyninst tag to check.exp
23866   dissonance between kernel tracepoint parametrization, lkm vs bpf
24811   stapbpf segfault: nested foreach loops can corrupt sorted key data
when limit==0
11353   elide side-effect-free probes
24528   stapbpf-next housekeeping: bpf-translate.cxx should distinguish
codegen for kernel/userspace targets
24543   stapbpf breaks when cpu0 is disabled
12025   Have appropriate selection of hex and decimal formatted output for
automatic output
24639   "next" statement not recognized by stap bpf backend
24343   Some syscall.*.return missing name and retstr variables
Read more

today's howtos