diff -u: What's New in Kernel Development
There's an ongoing impulse among a diversity of developers to be able to compile some or all of the Linux kernel as a library, so that a piece of software could use kernel services and APIs while running under a different kernel entirely, or a different operating system.
This time, the impulse came from Octavian Purdila, creator of the Linux Kernel Library (LKL), essentially an entire kernel compiled as a static library. He distinguished LKL from projects like User Mode Linux (UML), saying that LKL was more lightweight, having no infrastructure requirements or needing any particular sort of runtime environment.
A bunch of folks expressed interest, especially in terms of interacting with similar projects like libOS and libguestFS. And, Richard Weinberger remarked that LKL seemed to solve UML's biggest pain points: the need to use ptrace() to handle system calls and to do virtual memory management using SIGSEGV.
In a device-centric world with heavy, inefficient battery technology, there's a big incentive to figure out ways to save power. One possibility is to turn off portions of hardware when they're currently not in use, like a phone's touchscreen when the phone is in your pocket.
The difficulty lies in knowing exactly which piece of hardware to turn off, and when. If there's a clear user action, like flipping closed a flip-phone, the problem is simplified. Irina Tirdea recently tried to recognize such actions and come up with mechanisms to respond to them properly. She posted some patches to do this.
Octavian Purdila, also working on the project with Irina, described a target scenario as being when a touchscreen has been blanked but is still aware of the user's touch—through the fabric of a pocket, for example. The goal of the patches, he said, would be to save power by turning off all the hardware associated with that screen, and turn everything on again when the user activates the device.
The problem with this sort of feature is that it could be implemented along any of a number of different layers of the kernel code. The ideal location could make the difference between a complex, easily broken implementation and a simple, efficient implementation. Several folks felt that Irina and Octavian's approach was in the wrong part of the kernel, and the discussion devolved into a consideration of completely different approaches.
No consensus arose, although the allure of power-savings will undoubtedly keep the debate alive.
Mounting a filesystem under a virtual machine can be tricky. Security privileges and restrictions need to be respected, or else a filesystem could become a vector of attack by a malicious user. This particular area of kernel development also tends to have a wide appeal among companies trying to support their products, so it's possible for a variety of developers to find themselves working at cross purposes and need to accommodate each other before their patches can be accepted.
Seth Forshee and Eric Biederman, for example, recently wrote some patches to allow mounting Ext4 and FUSE filesystems by unprivileged users, ignoring the security information that otherwise might prevent those users from accessing that data.
Meanwhile, Lukasz Pawelczyk was working on code specifically to support that same security information.
A debate sprang up over the particular context involved. Andy Lutomirski suggested that if a filesystem contained a user's own data, it would be fine to override security features, on the grounds that users should be able to do what they wanted with their own data. While Casey Schaufler replied that the kernel shouldn't care what the user knew about the data, it had to follow the security protocols or else it wouldn't be able to enforce them at all.
On the other hand, as Eric pointed out, filesystems like FAT and Minix weren't capable of storing the same type of security information as more modern filesystems. There had to be a way, he said, to mount such filesystems without requiring them to support security features they couldn't support.
It's an ongoing debate. Security trumps all other considerations, including dire need, so an issue like unprivileged filesystem mounts inevitably will involve a consideration of the specific context in which a user might try to do something. Often there's some kind of crazy nuance that makes something feasible when you could have sworn it never would be feasible.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide