Aggregator

Red Hat Enterprise 8 Now Available, Microsoft Announces New Windows 10 Terminal App, Microsoft and Red Hat Announce an Open-Source Kubernetes Event-Driven Autoscaling Service, StackRox Partners with Red Hat, and Ubuntu 19.10 to Be Called Eoan Ermine

2 weeks 4 days ago

News briefs for May 7, 2019.

Red Hat Enterprise 8 is now available. From the press release: "Red Hat Enterprise Linux 8 is the operating system redesigned for the hybrid cloud era and built to support the workloads and operations that stretch from enterprise datacenters to multiple public clouds. Red Hat understands that the operating system should do more than simply exist as part of a technology stack; it should be the catalyst for innovation. From Linux containers and hybrid cloud to DevOps and artificial intelligence (AI), Red Hat Enterprise Linux 8 is built to not just support enterprise IT in the hybrid cloud, but to help these new technology strategies thrive." There will be a press conference tomorrow, May 8, at 11am EDT. You can register here.

Microsoft yesterday announced a new Windows 10 Terminal app for command-line users. From Microsoft's blog post: "Windows Terminal [is] a new application for Windows command-line users [that] will offer a user interface with emoji-rich fonts and graphics-processing-unit-accelerated text rendering. It also will provide multiple tab support as well as theming and customization, allowing users to personalize their Terminal." Windows Terminal will be available for Windows 10 systems sometime in June.

In other Microsoft and Red Hat news (the Build 2019 developer conference and Red Hat Summit both are this week), the two companies announce an "open-source service for auto-scaling serverless containers on Kubernetes". ZDNet reports that "Microsoft and Red Hat have jointly developed an open-sourced Kubernetes event-driven autoscaling (KEDA) service. KEDA enables developers to deploy serverless containers on Kubernetes in any public or private cloud, as well as on-premises, Microsoft officials said."

StackRox announced this morning that the StackRox Kubernetes Security Platform is now available as a Red Hat certified container. From the press release: "As part of the Red Hat Container Certification, StackRox's award-winning capabilities, powered by its container-native and Kubernetes-native platform, will be available through the Red Hat Container Catalog. Enterprise customers who use the production-ready Kubernetes platform offered by Red Hat OpenShift to deliver shorter application development cycles and better-quality software now have easier access to enhanced security and compliance capabilities certified by Red Hat." You can read more about the StackRox and Red Hat partnership here.

Ubuntu 19.10 is going to be called the "Eoan Ermine" release. Phoronix reports that "An Ermine is a stoat, or a short-tailed weasel. Eoan, as a reminder, means 'relating to the dawn or the east.'... So Ubuntu 19.10 is the dawn of the short-tailed weasel and will be out in October." This release is expected to bring "Linux 5.3, GNOME 3.34, Mesa 19.2, potentially Python 3 as the only Python version in the main archive, the X.Org session to still be the default, a new desktop installer that offers tight integration with the ZFS file-system, and many other changes for what they hope to send through this cycle for vetting ahead of the Long Term Support cycle."

News Red Hat RHEL Cloud Containers DevOps Microsoft Kubernetes StackRox Ubuntu
Jill Franklin

Rewriting printk()

2 weeks 4 days ago
by Zack Brown

The printk() function is a subject of much ongoing consternation among kernel developers. Ostensibly, it's just an output routine for sending text to the console. But unlike a regular print routine, printk() has to be able to work even under extreme conditions, like when something horrible is going on and the system needs to utter a few last clues as it breathes its final breath.

It's a heroic function. And like most heroes, it has a lot of inner problems that need to be worked out over the course of many adventures. One of the entities sent down to battle those inner demons has been John Ogness, who posted a bunch of patches.

One of the problems with printk() is that it uses a global lock to protect its buffer. But this means any parts of the kernel that can't tolerate locks can't use printk(). Nonmasking interrupts and recursive contexts are two areas that have to defer printk() usage until execution context returns to normal space. If the kernel dies before that happens, it simply won't be able to say anything about what went wrong.

There were other problems—lots! Because of deferred execution, sometimes the buffer could grow really big and take a long time to empty out, making execution time hard to predict for any code that disliked uncertainty. Also, the timestamps could be wildly inaccurate for the same reason, making debugging efforts more annoying.

John wanted to address all this by re-implementing printk() to no longer require a lock. With analysis help from people like Peter Zijlstra, John had come up with an implementation that even could work deep in NMI context and anywhere else that couldn't tolerate waiting.

Additionally, instead of having timestamps arrive at the end of the process, John's code captured them at execution time, for a much more accurate debugging process.

His code also introduced a new idea—the possibility of an emergency situation, so that a given printk() invocation could bypass the entire buffer and write its message to the console immediately. Thus, hopefully, even the shortest of final breaths could be used to reveal the villain's identity.

Sergey Senozhatsky had an existential question: if the new printk() was going to be preemptible in order to tolerate execution in any context, then what would stop a crash from interrupting printk() in order to die?

John offered a technical explanation, which seemed to indicate that "panic() can write immediately to the guaranteed NMI-safe write_atomic console without having to first do anything with other CPUs (IPIs, NMIs, waiting, whatever) and without ignoring locks."

Go to Full Article
Zack Brown