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
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:
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 - 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:
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.
(See also: Wikipedia
for more information on Controller Area Network).
to post comments)