On Wed, 23 Mar 2011, Alan Cox wrote: > Much of this depends upon what the data is and what it changes. Things > like interface names for example shouldn't be kernel mangled on the whim > of random board vendors. They follow a unified behaviour *across* > platforms, which is what matters most in the bigger picture. And that's exactly what we're trying to restore on the Panda. It happens that the Panda has an ethernet connector backed by an USB to Ethernet bridge, but the kernel currently decides to rename its network device from eth%d to usb%d, and assign it a random MAC address on each boot. What we want _is_ a more unified behaviour with other platforms. > Other stuff is to all intents and purposes sometimes hard coded into > drivers because while they are USB drivers they are checking specific > vendor id fields and changing behaviour on them. In some cases those > vendor id fields are actually a specific hardwired device. Here we're talking about a plain standard chipset but which happens in this case to be soldered directly on the board without the usual EEPROM which would have been used to distinguish this particular case otherwise. All we have left is the board specific code where the kernel knows on which board it is dealing with, from where we can tell that one particular instance of that USB device should be used in some unexpected way in order to present user space with an unified behaviour with other similar platforms. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
