Author Archives: mindlinux

Ten Years of OIN – Keith Bergelt, OIN

OIN was set up to avoid things like the SCO suite in the future. It was created by Redhat, Novell, … . The current rate of adoption is 150 licensees per quarter.

OIN protects, but also enables and influences government.

OIN makes an explicit expression of the idea of cooperation: there is a “system” zone of cooperation and non-agression, and a “Market” zone with competition. It’s a cultural norm rather than just a license.

When joining OIN, core Linux patents should be transferred to OIN but other patents are cross-licensed. In addition it makes defensive publications against future patents.

The only companies that have rejected the OIN commitments are companies that want to reserve the right to sui whin the Linux core OS.

Kernel Developer Panel – Moderator Grant Likely, Panelists: Kristen Accardi, Stephen Hemminger, Kevin Hilman, Greg Kroah-Hartman, Julia Lawall

Is there room for more developers in the kernel community?

We actually need more people, there are many drivers and subsystems that are not maintained. Maybe people hesitate to contribute because they’re not sure if they’re doing it the proper way. There is a mentorship program (Outreachy) but that’s 4 months and after that they are often a bit lost about what to do next. One thing kernel developers can do is to help a maintainer a bit e.g. when they go on vacation. And of course, doing reviews. In this community, nobody is going to tell you what project to work on, you have to take initiative and submit a patch. People should be invited more to become a maintainer.

Are we able to handle the complexity that we currently have in the kernel?

Yes, we’re doing complex things because it’s complex hardware, but we are fortunate to have all the code so you can actually look at what’s going in. But we do need to step up with CI etc. to handle things better.

There is actually also an opposite movement, with better APIs that hide some of the details. There is also a lot of infrastructure to write tools to analyse or modify code.

A lot of networking stuff is moving to userspace or ASICs. Does this make sense or are we creating fragmentation?

The kernel community doesn’t have a problem with fragmentation, it’s the people that do it that have a problem.

Can we handle the complexity of the different power management use cases?

There is indeed a lot of diversity in different needs from the hardware. But the kernel philosophy is not to do policy, so the complexity is largely pushed into userspace. The big piece that is happening lately is getting energy awareness in the scheduler, and it’s still going to take a while to figure out how to do that and how it interacts with the existing device PM subsystem.

How do we handle the issues of securing integrity of the systems and of data?

Mainly, detecting and fixing bugs (using static analysis and testing). IoT devices can never be updated, but that’s foolish.

What is the thing you’re most excited about

  • All of the different devices that are coming, e.g. IoT, for which we can create technical solutions.
  • It’s one of the few projects that works across a really wide variety of countries and cultures.
  • With kernelci, Kevin is getting more hardware and he’s excited to see all of that.
  • Seeing the bizarre new driver types that result in new subsystems.
  • The kernel is an infinite source of things to be cleaned.

What are the areas that need more focus?

  • Scaling, we need more maintainers.
  • Maintainer burnout.

We have maintainers who have been in their roles for many many years; do we encourage people to look for others to help them. You have to push the maintainers to give their thing away (without giving up maintainership).

Suspend/Resume at the Speed of Light – Len Brown, Intel

Linux suspend types: disk, mem (ACPI S3), (standby but nothing really supports it), freeze. Suspend-to-mem turns everything off except what is needed to turn on again. Low power idle is an additional state (not ACPI S3) is a state that doesn’t turn everything off and resumes a lot faster. freeze is the lowest power state that allows fast resume; this can be just an active idle state if low power idle doesn’t exist.

Low power idle is treated as a system suspend by Linux, even though not all devices are turned off.

Handheld devices wake up to do almost nothing (getting some wifi/data packet that needs little processing). Therefore, the power spent on suspend/resume itself becomes dominant compared to the compute time. Shortening the suspend/resume time therefore reduces energy consumption.

To go faster: eliminate waiting, do things in parallel, work asynchronously, or avoid work entirely.

To make things go faster, you first need measurements. Stopwatch and camera are good tools to start with, but doesn’t tell you what exactly happened. initcall_debug gives dmesg measurements of resume functions. analyze_suspend.py (https://github.com/01org/suspendresume), run as root, uses ftrace. It gives graphical display of the suspend and resume devices in an HTML page. It shows only the kernel resume, not userspace. Firmware resume (i.e. what BIOS/UEFI adds) is not included in the graph but it is reported (it’s not always reliable).

Currently in system suspend, there is no tracking of dependencies between devices. Instead, a device just declares itself synchronous, and all synchronous devices are serialized.

With -f option, you also get a call trace in the HMTL with timing info.

By turning a bunch of things of, you can get down to 60ms suspend-resume cycle (normally it’s 1.6s resume time…).

To improve suspend, we should make sure that devices are run-time suspended when you go to system suspend, they stay run-time suspended and are not resumed. Wifi association could also be improved.

Current Challenges in UBIFS – Richard Weinberger, Sigma Star GmbH

UBI is … a kind of LVM for flash devices. Static volumes have checksumming (i.e. consistency is guaranteed), dynamic volumes don’t. UBIFS doesn’t use OOB, because you don’t know how much is available (e.g. it could all be used for ECC).

UBIFS is powercut tolerant, as opposed to almost all FTL devices (the device itself is often not powercut tolerant).

Flash chips are getting cheaper and bigger by using lower quality techniques, so even the reliability of SLC is not so great anymore.

Fastmap keeps a fixed pool of “open” blocks which will need to be scanned while attaching. When all of these have been written, a new fastmap checkpoint is written. The blocks containing the fastmap itself are pointed to by a superblock, which must be within the first 64 EB of the partition (arbitrary number). Usually the fastmap is a single block and is merged with the superblock. To enable fastmap, set CONFIG_MTD_UBI_FASTMAP=y and (once) set the fm_autoconvert UBI module parameter to 1; once the fastmap has been created it will be used. ubinize doesn’t create the fastmap, because it doesn’t know what the bad blocks are so can’t predict the exact location of each block.

Since 3.15, ubiblock (= UBI volume as RO block device, cfr. mtdblock, ideal for squashfs) is mainlined.

Since 4.0, online renaming of volumes is mainlined. Makes dual image upgrade much easier.

Data retention was not a big deal when UBI was created. Nowadays, both for MLC and SLC, read disturb is important: when you read a page very frequently, nearby pages may get corrupted (note: this gets worse when the flash has been erased a lot). Solution: read everything occasionally, so ECC detects bitflips and scrubs the block. It’s not sufficient to just read /dev/ubi0_X, since then you don’t read the metadata. So instead, a new ioctl to get usage statistics, and a userspace daemon ubi-healthd to decide if it’s time to do scrubbing. Since only relative info is needed, there’s no need to store the statistics on flash.

Paired pages: when writing a page, and a powercut happens, another page may get corrupted as well. Several solutions are being evaluated, see ELC presentation by Boris Brezillon.

Bitflips on empty space: UBIFS detects empty space by comparing with 0xff, so if there’s a bitflip in empty space, UBIFS assumes that a powercut has happened there. If there is ECC on erased blocks that’s OK, but not all NFC support that.

Recent patches add quota and access time support to UBIFS, so it can also be used for large data storage.

An unpacker is being created to be able to read a UBIFS image offline. This can be used to do an offline fsck and find out what went wrong.

Common UBIFS misuses: A separate UBI image for each UBIFS volume… this reduces the amount of space available for wear levelling. UBIFS in the bootloader: that’s way too much overhead, just support a static RO volume for the kernel, that’s much much easier (few hundres lines of code). There’s an implementation of fastmap in U-Boot, but it’s currently broken since it’s based on the old experimental code.

Although MLC has already been around for five years, people only care about it now because in the past we just used SLC or eMMC.

Unstable bit problem: a powercut during a block erase may create unstable bits which can never be read reliably anymore. However, this issue has never been demonstrated in practice.

OpenEmbedded: If We Had to Start All Over, What Would We Do Different – Koen Kooi, Linaro

OE was started as a way to test drivers in TI (but done in the Chris Larson’s spare time). It had to be ‘one source tree, multiple configurations’.

Orthogonality between machine description, distro description, and the image.

MACHINE.conf defines arch tuning, kernel recipes, machine features, …

DISTRO.conf sets policy: Select ABI, compiler, C library, init system, package versions, package manager. PACKAGE_CONFIG tweaks sets options for packages.

image.bb is a selection of packages to install, and additional processing steps to actually create the image.

Layers were only added in 2010 for the Yocto Project. Split off the core section, with a maintainer and reviews. All the other stuff goes to separate git repos. But there were no real rules, slightly improved by introducing the “Yocto Project Compatible” stamp. Also a silo mentality since layers tend to look at themselves only. There’s an index of existing layers that also allows you to search for recipes and machines.

What is needed

Document use cases, e.g. what an SDK is good for, board bringup, creating a product.

Be more explicit what OpenEmbedded is not: not for application developers, not a distro, not yocto.

OE should respect the end user more: support external toolchains, support binary GPU drivers that depend on specific other packages (e.g. X), support ancient kernels.

More metrics about time spent, disk space needed, license checking, checking for wrong rpath.

Split off the image building as a separate tool, i.e. only build packages.

Get rid of FEATURES variables, it doesn’t match the philosophy. Similarly, make the split between machine, distro and image more mandatory.

Better tools for tracing why something gets added to the image or configured in a specific way.

Tools to empower maintainers: checkpatch, get-maintainer.

Maintainers should have the power to maintain: decide if a patch is accepted or not.

Pull requests are dangerous, since the tree you pull may not be exactly what was posted in the mailing list.

ELC-E / LinuxCon 2015 (Dublin) Monday keynotes

Since the keynotes are usually not terribly interesting, I’m collecting all of them on a single page.

Opening Remarks – Jim Zemlin

Man vs. Machine: High Frequency Trading and the Rise of the Algorithm – Sean Gourley, Quid

Transforming for the Digital Economy with Open Technology – Stefanie Chiras, IBM

The Future of Drones & Open Source – Lorenz Meier, Dronecode Project and Tully Foote, Open Source Robotics Foundation

Continue reading