Dynamic devices and static configuration

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:

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.

---

(Log in to post comments)