Kernel space: Linux gets CAN support

The Controller Area Network (CAN) specification describes a networking stack aimed at a specific environment: embedded, realtime controller networks. At the physical layer, it uses a differential serial technology which is intended to be highly resistant to electrical noise. The higher-level protocols use short datagrams (eight bytes maximum payload) and extensive checksumming to minimize the effect of errors. The protocols are simple in the extreme, placing the smallest possible demand on embedded controllers. CAN will be found in relatively small and hostile environments - inside automobiles, for example. So it makes sense that an automobile manufacturer—not the sort of company known for leading-edge Linux kernel development—is working to get a CAN implementation into the mainline kernel.

There have been CAN implementations on Linux before, though none have made their way into the mainline. Most of them, however, have taken the easy way out: make a CAN controller look more-or-less like a serial port and implement the protocols at the application level. This approach works, but it loses the advantages of having a networking stack around. Any CAN application which wants to take advantage of queueing, quality-of-service controls, the familiar socket API, etc. must implement that functionality itself. All of this may soon change, though, as the PF_CAN protocol family patches posted by Urs Thuermann, Oliver Hartkopp, and several others, matures.

As would be expected, these patches add a new PF_CAN protocol family which can be passed to the socket() system call. From there, sockets can be bound, read from, and written to in all the usual ways. Basic raw sockets can be used to send and receive datagrams on the (broadcast) bus. There is a mechanism for adding filters so that only datagrams of interest are received on a given interface. The PF_CAN implementation also comes with network drivers for a number of CAN interfaces. All told, it looks about as one would expect for a new network protocol family within the kernel. With this code in place, applications using CAN look almost like any other network-based Linux application.

What caught the author's eye with this patch set was the fact that it is being posted by some developers at Volkswagen. It is not uncommon to see Linux used in any number of embedded applications, and it is not surprising to see companies extending Linux in ways which make it more useful for their purposes—the ability to do so is one of the reasons for using Linux in the first place. But it is rather less common to see companies whose core competence is far from kernel hacking try to contribute changes back to the mainline. So the author dropped Mr. Thuermann a note asking a few questions about this work. It turns out that creating network-based CAN support for Linux has been a long task:

Quite a few CAN programmers come from a micro-controller background and have difficulties understanding our network oriented approach. On the other hand, network oriented people often find some designs in PF_CAN strange, where CAN makes it difficult (i.e. no addresses, not really layered) to have it look like other networking protocols. Therefore, it has taken us more than one year of discussion on the socketcan mailing list to achieve and agree on the current design.

The resulting patch set is just now getting close to its culmination; Urs would like to encourage anybody who is interested in how the CAN implementation has been designed to look at the documentation and the mailing list archives before jumping in.

The next question that tends to come to mind is something along the lines of "how do I get root access on my VW?" It turns out that the combination of Linux and CAN is not—yet&mdashbeing shipped in any of VW's cars. It is heavily used in a number of research projects, though; Urs mentioned potential applications in user interfaces, "infotainment," navigation systems, car-to-car communications, and more. CAN is also used to communicate with onboard systems from external diagnostic and monitoring systems. Whether Linux/CAN-based systems will ever find their way into production vehicles from VW remains to be seen. As Urs put it:

Let's wait and see if this becomes true :-) But I wouldn't bet on it. If you see the source disk in the glove box of your newly purchased car, that'd be really cool.

Regardless of what one manufacturer decides to use, though, it seems clear that there should be plenty of potential users for a CAN implementation which is properly built into Linux. Handheld gadgets are only a subset of the embedded application space; many complex embedded systems will need this sort of simple, resilient communications infrastructure.

First, though, this code needs to find its way into the mainline. The CAN developers had a bit of a disconnect with the networking maintainers back in August which will not have helped that cause. The issues would appear to have been resolved, and the CAN developers are posting patches and fixing the issues which are brought up by reviewers. Inclusion in 2.6.24 seems highly unlikely, but one more development cycle might be enough to get this code into shape for merging.

All things considered, a bump or two during the review process for a patch like this is not particularly surprising. Companies like Volkswagen are not in the habit of contributing kernel patches. Instead, VW has done some work which was useful for its own purposes and is now making the (considerable) extra effort to share that code with the rest of the world. VW's developers do not work with the development process every day; it is not surprising that some friction resulted here. To their credit, those developers managed to overcome the issues and appear to be sticking with the process through to the end.

This story could be repeated many times, for better or for worse. There will be no end of companies adapting Linux to their specific needs - that is why some of them will use free software in the first place. If we are lucky, some of those companies will try to contribute their work back so that others can make use of it and improve on it. These companies will not be familiar with our processes and may lack the time and the will to persevere in the face of a hostile reaction. Finding ways of helping these companies get their work into the mainline would appear to be in everybody's interest; otherwise we may well lose contributions we would have rather merged.