LWN.net Weekly Edition for November 6, 2014

The Dronecode collaborative project

The Linux Foundation (LF) announced a new project called Dronecode in mid-October, during LinuxCon Europe. The project is a collaboration of developers working on open-source unmanned aerial vehicle (UAV) software. UAVs (a.k.a., drones) may sound like a rather small niche, and one that involves a lot of per-vehicle specialization—factors that might make one ask why a collaborative "umbrella" organization is needed at all. The answer would seem to be that commercial drone makers have concerns about legal and regulatory issues—which a non-profit structure may be more advantageous to work within. Hopefully, though, the new project will benefit everyone who works with UAVs, hobbyists included.

The Dronecode announcement was made on October 12. In the press release, LF Chief Marketing Officer Amanda McPherson explained that the idea for the project came from executives at 3D Robotics, a commercial UAV manufacturer. Joining 3D Robotics as founding members are several other drone makers, such as Yuneec, Walkera, jDrones, and Squadrone, plus two companies that sell drone-related data services. SkyWard focuses on remote flight monitoring and routing, while DroneDeploy focuses on data capture. In addition, there are several other general technology companies involved, like Intel and Qualcomm.

In the LF announcement, the initial emphasis of Dronecode seems to be on a pair of open-source projects: APM and PX4. APM is an autopilot system that is developed largely at 3D Robotics. The lead maintainer is Andrew "Tridge" Tridgell, who is well-known within the open-source community for a variety of projects (most notably the Samba file server), although he is not a 3D Robotics employee. PX4 is also an autopilot system, although it is developed by a distributed team that is led by several Swiss research laboratories.

The difference, though, is that PX4 is designed for "DIY" (do-it-yourself) class devices, whether built by hobbyists or in classrooms. APM targets higher-end systems, and it addresses not only multi-rotor helicopter hardware (which is the most common DIY drone form factor), but fixed-wing aircraft as well.

An October 13 announcement at the Dronecode site indicated that several other open-source projects would also be developed under the Dronecode umbrella, including MissionPlanner, DroidPlanner, and MavLink. MissionPlanner and DroidPlanner are applications for plotting flight paths (for desktop systems and Android, respectively). MavLink is a UAV-to-ground communication protocol. Altogether, there are quite a few software components that go into building and safely operating a UAV, so there will likely be no shortage of work for Dronecode developers to devote their time to.

It is worth noting, though, that the other factor that may contribute to the decision of many of these projects to band together is that as drone technology has improved, governments are increasingly taking note and, on occasion, stepping in with regulation. Paul Fraidenburgh at Computerworld pointed out that the US Federal Aviation Administration (FAA) made several key decisions about the commercial usage of drones in September 2014.

Those decisions approved drones that adhere to specific weight restrictions and operating conditions—such as properly monitoring and maintaining the UAV's altitude, within specified limits that do not interfere with manned aircraft. And maintaining altitude is a software problem—one that drone makers will have to take seriously in order to avoid potential conflicts with the FAA that might ground a company's UAVs. UAVs, like any vehicle, must adhere to all FAA regulations, but the altitude limitation was a major sticking point; the FAA's initial rules limited UAVs to below 400 feet (122 meters).

Writing at ZDNet, Steven J. Vaughan-Nichols noted that one aerospace research firm recently predicted the total market expenditure on UAVs would hit US $91 billion dollars within a decade. It is certainly nowhere near that level today, but the commercial uses of drones (such as in film production) are a major money-making opportunity. The Dronecode site points out that there are far more uses, including humanitarian relief and scientific research, but the more lucrative business opportunities are no small factor.

All of the companies and researchers interested in pushing the state-of-the-art in drone software have reasons to band together and collaborate. Establishing a common platform will result in fewer software products that need to be investigated and approved by government regulatory agencies, and collaborating in an open-source project is well-established as one of the quickest ways to accelerate a product's development cycle.

Fortunately, the founding members of Dronecode have a proven history both of working in the open and of considering the needs of DIY projects as well as commercial entities. APM and PX4, for example, run on many hobbyist systems as well as high-end vendor products. Tridgell, in addition to serving as APM maintainer, will also be taking on the role of chairing Dronecode's Technical Steering Committee. Where UAV technology will be a few years down the road is hard to predict, but broad collaboration will surely help.

Comments (none posted)

A control group manager

CGManager is a year-old project to develop a daemon to manage control groups (cgroups) on a Linux system. These days, it is mostly targeted at doing that management for LXC containers, but it was originally envisioned as an alternative to systemd's cgroup management for those distributions that were not using systemd as their init. LXC maintainer Serge Hallyn gave a presentation about CGManager on October 13 at LinuxCon Europe in Düsseldorf, Germany.

Hallyn began his talk by saying that he and others didn't really care about CGManager, per se, but need the features that it currently provides. If there are alternatives that can still solve the problems that LXC has, he is not tied to keeping CGManager around. He hoped that conversations during the week (at LinuxCon, the containers track at Linux Plumbers, and the systemd hackfest) would be productive in that regard.

Background

Control groups started out as "task containers" when they were first introduced in 2007, Hallyn said. The idea was to add core kernel functionality to group tasks, along with code for tracking and limiting resource usage of each group as a whole. Task containers were eventually renamed and, over the years, controllers for resources like memory, CPU, block I/O, and so on have been added. Cgroups are administered through a filesystem interface.

Containers are an operating system (OS) level virtualization mechanism that uses many different kernel features to emulate virtual machines (VMs). Containers provide a separate, clean environment for the processes they contain using just the base OS, without any hardware support (unlike full virtualization solutions such as KVM). He called containers a "user space fiction" that builds on cgroups, bind mounts, namespaces, and other features to give the illusion of isolated systems. In addition, containers can be used without requiring privilege and they can be nested, he said.

CGManager was born out of the need for safe, unprivileged, nested containers. The cgroups maintainer (Tejun Heo) discourages the delegation of portions of the cgroup filesystem (cgroupfs) to unprivileged processes, Hallyn said, which was the mechanism used by LXC to support unprivileged containers in the past. Thus, CGManager avoids the need to grant safe access to cgroupfs to other processes and prevents processes from "escaping" into parent cgroups, even if they are root within the container.

In order to support that use case, he proposed the idea of CGManager in November 2013. Since that time, it has been developed and is in use by LXC, upstart, systemd-shim, and libvirt on Ubuntu and other systems.

Design

There is one CGManager daemon per host and requests to it are sent over D-Bus. The kinds of requests that are made are things like "create a new cgroup" or "move this process into that cgroup". D-Bus uses a Unix-domain socket, so the SCM_CREDENTIALS message can provide the UID, GID, and PID of the requesting process; the kernel will translate them to the appropriate value in the receiving namespace.

But when a request to move a process to a new cgroup is sent to CGManager, the PID used to identify it is local to the requesting process's namespace. CGManager would somehow have to translate that to the PID in the root namespace, but that is tricky to do. One possibility would be to use the setns() system call to put CGManager into the namespace of the requester. There are two problems there, however. For one, he wanted to be able to support kernels prior to the introduction of setns() in 3.0. More importantly, though, switching to the requester's namespace could cause CGManager to lose the privileges it needs to do its job: possibly including the ability to switch back to the root namespace.

Beyond those problems, though, he wanted users of CGManager to be able to send simple D-Bus requests, without adding credentials or doing anything special. So there is a proxy that lives in each container to accept simple D-Bus requests and translate them to requests with credentials to send to CGManager. It is worth noting that the proxies cannot chain, as their input and output have different characteristics; the proxies talk directly to CGManager, no matter how deeply nested they are. Chaining them could introduce performance problems for deeply nested containers, he said.

The standard socket for CGManager is created at /sys/fs/cgroup/cgmanager/sock. LXC bind mounts the /sys/fs/cgroup/cgmanager directory into each container. The proxy moves the cgmanager directory aside and puts its own socket in its place. That way, processes inside and outside of containers do not have to be aware of the difference.

Hallyn listed the 18 or so D-Bus methods that CGManager provides. They allow requesters to create cgroups, move processes to or from them, list processes in a cgroup, and so on. All of the requests are handled as being relative to the cgroup of the requester, so there is no way to create or access cgroups further up the hierarchy.

The GetValue and SetValue requests allow processes to set cgroup subsystem resource limits using the names currently exported by cgroupfs. There was discussion early on about creating an API to separate cgroup users from the exact names that are currently exported, but that has not happened. The idea is to allow the kernel to change those parameter names and other characteristics without requiring changes in various user-space programs. It is a "worthwhile goal", Hallyn said, but LXC has been exporting those names for longer than he has been maintaining it. For now, LXC will continue using them, but the project is willing to work on a higher-level API down the road.

Future

There are several alternatives for the future of CGManager, he said. One possibility is to enhance cgroupfs to virtualize cgroups. That would mean cgroups would not be able to see other cgroups that are above (or at the same level) in the hierarchy. Currently, /proc/self/cgroup and cgroupfs leak information about other cgroups. One way to avoid that would be via cgroups namespaces that have been proposed by Aditya Kali. That, coupled with the ability to fully delegate parts of the hierarchy to other processes, would obviate the need for CGManager. Since the cgroups maintainer does not favor that approach, though, it is unlikely, Hallyn said.

Another idea might be to move the functionality provided by CGManager into systemd. That would require enhancing the functionality of systemd slices and to allow users to specify sub-slices. In order to support the use cases that LXC users require, it would mean moving much of what CGManager does into systemd, and it is unclear whether that would be possible or not.

Lastly, CGManager could continue on. There are features that need work, including a higher-level API to abstract away the cgroupfs resource file names, that should be done in conjunction with others in the community. Support for the new "remove on empty" feature of cgroups is another. There is also work to be done on integrating with systemd, since CGManager will have to coexist with systemd on some systems. All of those topics were things he hoped to discuss with others during the week.

[ I would like to thank the Linux Foundation for travel assistance to Düsseldorf for LinuxCon Europe. ]

Comments (5 posted)

"Importing" data runs afoul of the ITC

Software developers who work and live outside of the US have taken comfort in being outside that legal jurisdiction, so they avoid the application of US patent law. However, the International Trade Commission (ITC), an arm of the US government that prohibits certain unfair business practices involving international trade, used a recent investigation as a chance to prohibit certain electronic transmissions from being sent into the US from outside the country. This is troubling for open-source communities and others, but businesses are fighting back.

The ITC report on the investigation, titled "Certain Digital Models, Digital Data, and Treatment Plans for Use in Making Incremental Dental Positioning Adjustment Appliances, the Appliances Made Therefrom, and Methods of Making the Same", initially looks rather mundane. In early 2012, California-based orthodontics company, Align Technology, claimed that its patents on orthodontics devices, and on systems and methods relating to those devices, were being infringed by Pakistan-based competitor ClearCorrect (which also operates in Texas). In its original March 2012 notice [PDF] to the public, the ITC characterized the alleged harm as stemming from the importation and manufacture for commercial purposes of those goods.

The alleged importation occurred when digital information that would be used to help make its products was transmitted electronically from ClearCorrect's Pakistan home to its Texas-based arm over the Internet. The issue of interest here for software developers, then, is whether or not information transmitted electronically into the US that could be used in patent infringing goods or services are "articles" being "imported" under the ITC's rules, and thus subject to its jurisdiction.

The ITC took a couple years to deliberate, with an initial determination made by an ITC administrative law judge in May 2013. The Commission's investigation came to a conclusion in April 2014, when it released its review [PDF] of the initial determination. In that review, the ITC found that ClearCorrect unlawfully transmitted its digital goods into the US, and ordered the company to cease and desist from further transmitting those specific goods into the country.

ClearCorrect appealed [PDF] soon after, with only mild success. It got a favorable ruling in July from the Court of Appeals for the Federal Circuit (CAFC), which ruled that the ITC had no legal authority to review the original judge's initial determination, but that determination still held that inbound electronic signals from outside the United States are imported articles.

Interested third-parties have decided to keep the case alive, as they are concerned about the impact the ITC's decision could have on them. In a recent amicus brief [PDF] to the CAFC, the Internet Association, a trade association made up of major companies including Twitter, Google, Amazon, Facebook, and Netflix, argued that the ITC had no legal basis to support its initial ruling. The organization formally asked the CAFC to overturn its decision. The Association's argument has five prongs:

First, that patents don't apply to transmissions of electronic information at all because they aren't physical goods: "Electronic transmissions lack the tangible, physical embodiment necessary to be eligible for patent-law protection." (page 6).

Second, that the ITC can't find a transmission infringing solely because it contributes to infringement after it is imported, despite the transmission alone not being infringing. At the time of importation, there was no infringement: "The holding below improperly treated the electronic transmissions as infringing articles even though the statute requires infringement at the time of importation" (page 7).

Third, that the ITC was wrong to say imported electronic goods can infringe method patents (like the patents on a method to use digital data sets to construct orthodontic devices, as in this case), because a method patent is just a recipe, and not an actual embodiment of an infringing activity: "Even if an electronic signal could be considered an infringing article, the ITC erred in holding that an article may infringe a method patent, which claims the performance of a series of steps, not a structure." (page 7).

Fourth, that the CAFC said repeatedly in past cases that the types of goods the ITC can prohibit have to be "tangible products" (page 8).

Lastly (and possibly most compellingly), that Congress didn't give the ITC any power to do what it's trying to do. The main stick that the ITC has to smack down what it sees as bad actors is the power to issue an "exclusion order". When the ITC issues an exclusion order, it's instructing US customs agents to block infringing goods from being brought into the country. Since it's totally impractical to tell border control to stop certain electronic signals from coming into the country, the ITC tried to get around the problem in this case by using a different stick: ordering ClearCorrect to cease and desist from importing its digital data sets relating to orthodontic devices via electronic transmission and from using the data sets already available to its Texas-based arm in its commercial products and services. However, written law states that the ITC can't use the latter stick if it can't use the former: "The ITC attempted to impose a cease-and-desist remedy, but the statute makes clear that the authority to issue cease-and-desist orders does not extend to cases where an exclusion order is unavailable" (page 9).

It is not hard to imagine how open-source enthusiasts would be concerned by an unsuccessful appeal. For example, Fedora does not package any software in its repositories that the project believes violate US patents. Some users (likely including at least a few US residents) get this software through third-party repositories, such as RPM Fusion. While the vast majority of RPM Fusion's public mirrors are hosted on servers outside the US, the fact that some of the contents may be transmitted to a US user who might engage in an infringing activity could make RPM Fusion subject to an ITC cease-and-desist order; an order to stop transmitting the infringing software into the US, with steep fines for non-compliance. That order could come about if some organization that holds US patents that read on some software provided by RPM Fusion made a complaint to the ITC. Enforcing the order on a non-US organization might be difficult for the ITC, but it would be somewhat painful, or at least annoying, for the organization in question.

The open-source community should be pleased by the fact that large Internet corporations are formally expressing their concern with this case. In addition, should the CAFC rule against ClearCorrect, an appeal to the Supreme Court, which has repeatedly disagreed with the CAFC's patent decisions, could result in an overruling. This case is one worth keeping an eye on.

Comments (9 posted)