PF_CAN

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 your editor'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 your editor 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:

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 - being 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:

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.

(See also: Wikipedia for more information on Controller Area Network).

---

(Log in to post comments)

Why are the guys of VW are working on CAN? Because they are sooo generous?
No. They just have a patent on PF_CAN, thats all.

Hi Uwe,

Volkswagen is a Car Manufacturer - not a software company. So it was quite hard for Urs and me
push our work to the public. When we had been able to license our work under GPL end of 2005
this was archived by the fact, that we had a government supported project
(http://www.network-on-wheels.de) together with BMW and Daimler, where we had been able to
share our LLCF/socketcan source. From this point (when the source was available for the
competitor) we had a good position to push our code to GPL in 2005 ;-) AFAIK the GPL forces
your own patents to be used for free, when you put your code under GPL (which we did). And
anyway there is no patent. Only a registration/publication which might be looked at in 7 years
- i think you know about the German patent office workflows. So regarding that software
patents in Germany are not granted and it turned out to be a good thing for Volkswagen to
license our work under GPL, there is no need nor any effort to be spent on this (not even
existing) patent. We've learned that now. Btw. Microsoft had 'adopted' our concept in their
latest "Windows Mobile for Automotive" with their 'WinsockAPI' - so our publication was worth
the work.

Finally Urs and me started end of 2002 with our first ideas. We used our software for our
vehicle prototypes (e.g. in the VW Up! instrument cluster on IAA2007). And even if Urs and me
are working on PF_CAN 50/50 in our spare time now (we do not have git behind the VW firewall)
Volkswagen IS that generous that we can work on OSS even if there is no new benefit for our
current projects. And i'm personally very proud of many positive feedback to us and Volkswagen
to support OSS.

Best regards,
Oliver