Linux users in the Good Old Days were treated to a number of experiences
which are denied to newcomers; one of those was the tiresome task of
figuring out where peripheral devices had chosen to put their I/O ports and
interrupt lines and communicating that information to the kernel.
Contemporary, self-describing hardware had taken a lot of the fun away in
the name of making things Just Work.
This kind of joy can still be had at the embedded level, though, where the
trend toward discoverable hardware has not caught on in the same way.
Recent discussions show that there is not, yet, a consensus among kernel
developers regarding how such hardware should be configured.
The OMAP-based PandaBoard is a popular
platform for those who are interested in experimenting with embedded
applications. It comes with a dual-core processor, high-definition video
capability, wireless networking, Bluetooth, an HDMI output, and the sadly
standard closed graphics usually associated with these devices. It also
has a "USB-attached" network port which is actually soldered to the board;
it looks like a USB device, but it's not something the user could unplug
without an act of significant violence.
This network port has moved developers toward violence for other reasons as
well. It is recognizable as a network device, but there is no way to know
that it is wired down. The board developers, in a move which is common in
this area, also left out the small EEPROM which would normally contain the
MAC address for this interface. In response to these design decisions, a
standard Linux kernel
booting on this board will call its network interface usb0 (a name
normally used for
USB point-to-point connections), and will generate a random MAC address for
it. Anybody who might depend on a MAC address which is stable across boots
will be out of luck.
This kind of non-discoverable hardware is common in the embedded sphere, so
a number of techniques have been developed to allow the kernel to run on
the resulting systems. The traditional approach is through the creation of
"board files"; see board-msm7x30.c as an
example. These files are meant to provide the kernel with enough
information to understand the topology of the hardware it is running on;
information related to specific devices is typically passed through a set
of static platform_device structures, and through that structure's
platform_data pointer in particular. As the driver initializes
the device, it can refer to the platform_data pointer (which
points to some sort of device-specific structure) for any information which
it cannot get from the hardware itself.
The current platform_data implementation will not work for the
PandaBoard, though, because platform_data is not passed to USB
devices. These devices are meant to be entirely discoverable and
self-describing, so it was thought that there would be no need for external
configuration data in the kernel. The fact that these devices are dynamic
means that their existence cannot be known or guaranteed when the board
file is written, so trying to create static platform data for them would
seem to make little sense.
The problem with this reasoning is that the PandaBoard's network interface is not
fully discoverable and it is not dynamic. It is a sort of platform device
disguised as a USB device. So Andy Green thought it would be reasonable to use platform
data as a way of configuring this device; in particular, he would like to
pass the device name (eth0 instead of usb0) and a MAC
address via a platform_data pointer. What he got was an extended
discussion making it clear that (1) the platform data mechanism is not
universally loved, and (2) there is not a complete consensus on how
this kind of problem should really be solved.
There are a couple of perceived problems with platform data; first of those
is that it encodes the information about a specific hardware configuration
in the kernel itself. That leads to a proliferation of board files in the
kernel source - each of which is controlled by its own configuration option
- and makes it hard to build kernels which can run on multiple boards. The
platform_data pointer itself, being a void pointer, is
seen as not being type-safe: there is no way for the compiler to ensure
that every board file is passing the right type of pointer to every device
driver. For these reasons, there is strong opposition to expanding the
platform data mechanism.
What are the alternatives? One of those is to do everything in user space,
using udev rules. This approach appeals to those who want to see
no policy in kernel space, but it is hard to implement in this case; there
is no information available to distinguish this wired-down network
controller from the traditional USB variety. Some developers are also
unconvinced that replacing in-kernel board files with fragile-looking (to
them) user-space configuration files which must be pushed to distributors
is the way toward a more robust solution. It is also argued that the
device naming policy (usb0, in this case) is already in the
kernel; the discussion is about the details of what that policy should be.
The other approach would be to use device
trees, which are meant for just this type of application. A device
tree would allow the passing of configuration-specific information into
drivers without the need to put board-specific hacks into the drivers
themselves. As more components show up in both consumer and deep embedded
situations, this capability will only become more useful. For these
reasons, Arnd Bergmann thought that this
problem would be an ideal place to demonstrate the use of device trees:
Let's make this the first use case where a lot of people will want
to have the device tree on ARM. The patch to the driver to check
for a mac-address property is trivial, and we can probably come up
with a decent way of parsing the device tree for USB devices, after
all there is an existing spec for it.
The problem with the device tree approach is that its adoption, in general,
is slow, especially in the ARM architecture which, arguably, has the most
need of it. It does not seem like a solution for people who have a
PandaBoard now and would like it to work; it is also not immediately
applicable to all of those systems which are currently described by board
files and platform data. While many people seem to see a transition to
device trees as something which will happen eventually, few of them are
holding their breath in anticipation of an immediate changeover.
So what is a PandaBoard owner to do? There are, it seems, a couple of
short-term solutions which will fix this particular board without waiting
for longer-term answers. One is a patch from
Arnd which will cause USB-attached Ethernet devices to carry
an ethN name unless they are known to be point-to-point
connections. For the MAC address problem, Alan Cox has suggested a hack which would allow the board
file to take control of the address assignment for a specific interface.
Neither of these solutions addresses the real problem, but they will give
some breathing room while the proper fix is debated.
to post comments)